针对特定任务设计能力

Designing Capabilities for Specific Tasks

工具通常是工具集是根据智能体要解决的任务量身定制的。在设计工具时，开发者必须考虑智能体在不同条件和环境下的表现。一套精心设计的工具集能够确保智能体精准高效地处理各种任务。工具可以分为三大类：

Tools are typically tailored to the tasks that the agent is designed to solve. When designing tools, developers must consider how the agent will perform under different conditions and contexts. A well-designed toolset ensures that the agent can handle a variety of tasks with precision and efficiency. Tools can be divided into three main categories:

本地工具

Local tools

这些操作是代理基于内部逻辑和计算执行的，不依赖于外部资源。本地工具通常基于规则或涉及执行预定义的功能。例如，数学计算、从本地数据库检索数据，或基于预定义规则进行简单的决策（例如，根据设定的标准决定是否批准或拒绝请求）。

These are actions that the agent performs based on internal logic and computations without external dependencies. Local tools are often rule-based or involve executing predefined functions. Examples include mathematical calculations, data retrieval from local databases, or simple decision making based on predefined rules (e.g., deciding whether to approve or deny a request based on set criteria).

基于 API 的工具

API-based tools

基于 API 的工具这些工具使智能体能够与外部服务或数据源进行交互。通过获取实时数据或利用第三方系统，这些工具能够帮助智能体将功能扩展到本地环境之外。例如，虚拟助手可以使用 API 获取天气数据、股票价格或社交媒体更新，从而为用户查询提供更具上下文关联性和相关性的回复。

API-based tools enable agents to interact with external services or data sources. These tools enable agents to extend their capabilities beyond the local environment by fetching real-time data or leveraging third-party systems. For instance, a virtual assistant might use an API to pull weather data, stock prices, or social media updates, enabling it to provide more contextual and relevant responses to user queries.

模型上下文协议（MCP）

Model Context Protocol (MCP)

基于MCP的这些工具使智能体能够利用模型上下文协议 (MCP)为语言模型提供结构化的实时上下文。MCP 是一种标准化的模式，用于将外部知识、记忆和状态传递到模型的提示中。与需要完整往返执行的传统 API 调用不同，MCP 使智能体能够将丰富的动态上下文（例如用户配置文件、对话历史、世界状态或特定任务的元数据）直接注入到模型的推理过程中，而无需调用其他工具。它们在减少冗余工具的使用、保留对话状态以及将实时情境感知融入模型行为方面尤为有效。

MCP-based tools enable agents to provide structured, real-time context to language models using the Model Context Protocol, a standardized schema for passing external knowledge, memory, and state into the model’s prompt. Unlike traditional API calls that require full round-trip execution, MCP enables agents to inject rich, dynamic context—such as user profiles, conversation history, world state, or task-specific metadata—directly into the model’s reasoning process without invoking separate tools. They are particularly effective in reducing redundant tool use, preserving conversational state, and injecting real-time situational awareness into model behavior.

本地工具使智能体能够利用内部逻辑和基于规则的功能独立执行任务，例如进行计算或从本地数据库检索数据；而基于 API 的工具则使智能体能够连接到外部服务。这使得智能体可以访问实时数据或第三方系统，从而提供与上下文相关的响应和扩展功能。功能性。

While local tools enable agents to perform tasks independently using internal logic and rule-based functions, such as calculations or data retrieval from local databases, API-based tools enable agents to connect with external services. This allows for the access of real-time data or third-party systems to provide contextually relevant responses and extended functionality.

工具集成和模块化

Tool Integration and Modularity

模块化设计这对于工具开发至关重要。每个工具都应设计成一个独立的模块，以便根据需要轻松集成或替换。这种方法使开发人员能够在不彻底改造整个系统的情况下更新或扩展代理的功能。例如，客户服务聊天机器人最初可能只配备一套用于处理简单查询的基本工具，之后可以添加更复杂的工具（例如，争议解决或高级故障排除），而不会影响代理的核心功能。运营。

Modular design is critical for tool development. Each tool should be designed as a self-contained module that can be easily integrated or replaced as needed. This approach enables developers to update or extend the agent’s functionality without overhauling the entire system. A customer service chatbot might start with a basic set of tools for handling simple queries and later have more complex tools (e.g., dispute resolution or advanced troubleshooting) added without disrupting the agent’s core operations.

短期记忆

Short-Term Memory

短期记忆指的是代理存储和管理与当前任务或对话相关信息的能力。这种记忆通常用于在交互过程中保持上下文关联，使代理能够实时做出连贯的决策。例如，能够记住用户在会话期间先前查询的客服代理可以提供更准确、更具上下文感知的回复，从而提升用户体验。

Short-term memory refers to an agent’s ability to store and manage information relevant to the current task or conversation. This type of memory is typically used to maintain context during an interaction, enabling the agent to make coherent decisions in real time. A customer service agent that remembers a user’s previous queries within a session can provide more accurate and context-aware responses, enhancing user experience.

短期记忆通常通过滚动上下文窗口来实现，它使智能体能够维护一个包含近期信息的滑动窗口，同时丢弃过时的数据。这在聊天机器人或虚拟助手等应用中尤为有用，因为智能体必须记住最近的交互，但可以忘记较早的、无关紧要的细节。

Short-term memory is often implemented using rolling context windows, which enable the agent to maintain a sliding window of recent information while discarding outdated data. This is particularly useful in applications like chatbots or virtual assistants, where the agent must remember recent interactions but can forget older, irrelevant details.

长期记忆

Long-Term Memory

长期记忆，另一方面，它使智能体能够长期存储知识和经验，从而利用过往信息指导未来的行动。这对于需要随着时间推移不断改进或根据用户偏好提供个性化体验的智能体而言尤为重要。

Long-term memory, on the other hand, enables agents to store knowledge and experiences over extended periods, enabling them to draw on past information to inform future actions. This is particularly important for agents that need to improve over time or provide personalized experiences based on user preferences.

长期记忆通常通过数据库、知识图谱或精细调整的模型来实现。这些结构使智能体能够存储结构化数据（例如，用户偏好、历史性能指标），并在需要时检索这些数据。例如，医疗保健监测智能体可以长期保存患者的生命体征数据，从而检测趋势或为医疗保健提供者提供历史数据。

Long-term memory is often implemented using databases, knowledge graphs, or fine-tuned models. These structures enable agents to store structured data (e.g., user preferences, historical performance metrics) and retrieve it when needed. A healthcare monitoring agent might retain long-term data on a patient’s vital signs, enabling it to detect trends or provide historical insights to healthcare providers.

记忆管理与检索

Memory Management and Retrieval

有效记忆管理包括组织和索引存储的数据，以便在需要时轻松检索。依赖记忆的代理必须能够区分相关数据和无关数据，并快速检索信息以确保流畅运行。在某些情况下，代理可能还需要遗忘某些信息，以避免记忆被过时或不必要的细节所占据。

Effective memory management involves organizing and indexing stored data so that it can be easily retrieved when needed. Agents that rely on memory must be able to differentiate between relevant and irrelevant data and retrieve information quickly to ensure seamless performance. In some cases, agents may also need to forget certain information to avoid cluttering their memory with outdated or unnecessary details.

电商推荐系统必须存储用户偏好和过往购买记录，才能提供个性化推荐。然而，它还必须优先考虑近期数据，以确保随着用户偏好的变化，推荐内容依然保持相关性和准确性。随着时间的推移。

An ecommerce recommendation agent must store user preferences and past purchase history to provide personalized recommendations. However, it must also prioritize recent data to ensure that recommendations remain relevant and accurate as user preferences change over time.

性能：速度/准确性之间的权衡

Performance: Speed/Accuracy Trade-Offs

智能体设计中的一个关键权衡在于速度和准确性之间的平衡。高性能通常能使智能体快速处理信息、做出决策和执行任务，但这可能会牺牲精度。反之，过分追求准确性可能会降低智能体的速度，尤其是在需要复杂模型或计算密集型技术时。

A key trade-off in agent design is balancing speed and accuracy. High performance often enables an agent to quickly process information, make decisions, and execute tasks, but this can come at the expense of precision. Conversely, focusing on accuracy can slow the agent down, particularly when complex models or computationally intensive techniques are required.

在自动驾驶汽车或交易系统等实时环境中，快速决策至关重要，毫秒之差有时甚至会造成决定性的影响；在这种情况下，为了确保及时响应，速度可能比准确性更为重要。然而，像法律分析或医疗诊断这样的任务则需要极高的精确度，因此牺牲一些速度来确保结果的可靠性是可以接受的。

In real-time environments, such as autonomous vehicles or trading systems, rapid decision making is essential, with milliseconds sometimes making a critical difference; here, prioritizing speed over accuracy may be necessary to ensure timely responses. However, tasks like legal analysis or medical diagnostics require high precision, making it acceptable to sacrifice some speed to ensure reliable results.

混合方法也行之有效，即代理首先提供快速的近似响应，然后通过更精确的后续反馈进行完善。这种方法常见于推荐系统或诊断系统中，其中快速的初始建议会随着时间和数据的积累而得到验证和改进。

A hybrid approach can also be effective, where an agent initially provides a fast, approximate response and then refines it with a more accurate follow-up. This approach is common in recommendation systems or diagnostics, where a quick initial suggestion is validated and improved with additional time and data.

可扩展性：代理系统的工程可扩展性

Scalability: Engineering Scalability for Agent Systems

可扩展性是对于现代基于代理的系统而言，尤其是那些严重依赖深度学习模型和实时处理的系统，计算资源管理面临着严峻的挑战。随着代理系统复杂性、数据量和任务并发性的增长，计算资源的管理变得至关重要，尤其是在处理大量数据方面。GPU（图形处理器）是加速大型人工智能模型训练和推理的核心，但要实现高效扩展，需要精心设计，以避免瓶颈、资源利用不足和运营成本上升。本节概述了通过优化 GPU 资源和架构来有效扩展智能体系统的策略。

Scalability is a critical challenge for modern agent-based systems, especially those that rely heavily on deep learning models and real-time processing. As agent systems grow in complexity, data volume, and task concurrency, it becomes critical to manage computational resources, particularly GPUs. GPUs are the backbone for accelerating the training and inference of large AI models, but efficient scaling requires careful engineering to avoid bottlenecks, underutilization, and rising operational costs. This section outlines strategies for effectively scaling agent systems by optimizing GPU resources and architecture.

GPU资源通常是扩展代理系统时最昂贵且最具限制性的因素，因此高效利用GPU资源至关重要。合理的资源管理能够帮助代理处理不断增长的工作负载，同时最大限度地降低高性能计算带来的延迟和成本。动态GPU分配是实现可扩展性的关键策略，它根据实时需求分配GPU资源。动态分配并非静态地将GPU分配给代理或任务，而是确保GPU仅在必要时使用，从而减少空闲时间并优化资源利用率。

GPU resources are often the most expensive and limiting factor in scaling agent systems, making their efficient use a top priority. Proper resource management enables agents to handle increasing workloads while minimizing the latency and cost associated with high-performance computing. A critical strategy for scalability is dynamic GPU allocation, which involves assigning GPU resources based on real-time demand. Instead of statically allocating GPUs to agents or tasks, dynamic allocation ensures that GPUs are only used when necessary, reducing idle time and optimizing utilization.

弹性 GPU 配置进一步提高了效率，它使用云服务或本地 GPU 集群，根据当前工作负载自动扩展资源。

Elastic GPU provisioning further enhances efficiency, using cloud services or on-premises GPU clusters that automatically scale resources based on current workloads.

优先级队列和智能任务调度进一步提高了效率，使高优先级任务能够立即获得 GPU 访问权限，同时在高峰时段将不太重要的任务排队等待。

Priority queuing and intelligent task scheduling add another layer of efficiency, giving high-priority tasks immediate GPU access while queuing less critical ones during peak times.

在大规模智能体系统中，延迟可能成为一个重要问题，尤其是在智能体需要在实时或近实时环境中交互时。优化延迟以降低延迟对于确保智能体保持响应速度并满足性能要求至关重要。在分布式系统中高效调度 GPU 任务可以降低延迟，并确保智能体在高负载下流畅运行。

In large-scale agent systems, latency can become a significant issue, particularly when agents need to interact in real-time or near-real-time environments. Optimizing for minimal latency is essential for ensuring that agents remain responsive and capable of meeting performance requirements. Scheduling GPU tasks efficiently across distributed systems can reduce latency and ensure that agents operate smoothly under heavy loads.

一种有效的策略是异步任务执行，它允许并行处理 GPU 任务，而无需等待先前的任务完成，从而最大限度地利用 GPU 资源并减少任务之间的空闲时间。

One effective strategy is asynchronous task execution, which enables GPU tasks to be processed in parallel without waiting for previous tasks to be completed, maximizing GPU resource utilization and reducing idle time between tasks.

另一种策略是跨GPU进行动态负载均衡，它通过将任务分配到未充分利用的资源上，防止单个GPU成为瓶颈。对于依赖GPU密集型任务（例如运行复杂的推理算法）的代理系统而言，有效扩展不仅仅是增加GPU数量；它还需要精心的优化，以确保资源得到充分利用，从而使系统能够高效地满足不断增长的需求。

Another strategy is dynamic load balancing across GPUs, which prevents any single GPU from becoming a bottleneck by distributing tasks to underutilized resources. For agent systems reliant on GPU-intensive tasks, such as running complex inference algorithms, scaling effectively requires more than simply adding GPUs; it demands careful optimization to ensure that resources are fully utilized, enabling the system to meet growing demands efficiently.

要有效扩展 GPU 密集型系统，需要的不仅仅是添加 GPU——它还涉及确保 GPU 资源得到充分利用，并且系统能够随着需求的增长而高效扩展。

To scale GPU-intensive systems effectively, it requires more than just adding GPUs—it involves ensuring that GPU resources are fully utilized and that the system can scale efficiently as demands grow.

水平扩展是指通过添加更多GPU节点来扩展系统，以处理不断增长的工作负载。在集群架构中，多个GPU可以协同工作，处理诸如实时推理或模型训练等高容量任务。

Horizontal scaling involves expanding the system by adding more GPU nodes to handle increasing workloads. In a cluster setup, GPUs can work together to manage high-volume tasks such as real-time inference or model training.

对于工作负载变化较大的代理系统，采用混合云方案可以通过结合本地GPU资源和云端GPU来提高可扩展性。在高峰需求期间，系统可以使用突发扩展，将任务卸载到临时云端GPU上，从而在无需永久性投资物理基础设施的情况下扩展计算能力。一旦需求下降，这些资源就可以释放，从而确保成本效益。

For agent systems with varying workloads, using a hybrid cloud approach can improve scalability by combining on-premises GPU resources with cloud-based GPUs. During peak demand, the system can use burst scaling, in which tasks are offloaded to temporary cloud GPUs, scaling up computational capacity without requiring a permanent investment in physical infrastructure. Once demand decreases, these resources can be released, ensuring cost-efficiency.

在需求较低、价格更优惠的非高峰时段使用基于云的 GPU 实例，可以显著降低运营成本，同时还能在需要时保持扩展的灵活性。

Using cloud-based GPU instances during off-peak hours, when demand is lower and pricing is more favorable, can significantly reduce operating costs while maintaining the flexibility to scale up when needed.

有效扩展代理系统（尤其是依赖 GPU 资源的系统）需要在最大化 GPU 效率、最小化延迟和确保系统能够处理动态工作负载之间取得平衡。通过采用动态 GPU 分配、多 GPU 并行、分布式推理和混合云基础设施等策略，代理系统可以扩展以满足不断增长的需求，同时保持高性能和成本效益。GPU 资源管理工具在这一过程中发挥着至关重要的作用，提供必要的监管以确保无缝扩展。随着智能体系统的复杂性和范围不断扩大。

Scaling agent systems effectively—particularly those reliant on GPU resources—requires a careful balance between maximizing GPU efficiency, minimizing latency, and ensuring that the system can handle dynamic workloads. By adopting strategies such as dynamic GPU allocation, multi-GPU parallelism, distributed inference, and hybrid cloud infrastructures, agent systems can scale to meet growing demands while maintaining high performance and cost efficiency. GPU resource management tools play a critical role in this process, providing the oversight necessary to ensure seamless scalability as agent systems grow in complexity and scope.

可靠性：确保代理行为的稳健性和一致性

Reliability: Ensuring Robust and Consistent Agent Behavior

可靠性是指可靠性取决于代理程序能否长期、持续、准确地执行任务。一个可靠的代理程序必须能够无故障地应对预期和非预期的情况，从而确保用户和利益相关者的高度信任。然而，提高可靠性通常需要在系统复杂性、成本和开发时间方面做出权衡。

Reliability refers to the agent’s ability to perform its tasks consistently and accurately over time. A reliable agent must handle expected and unexpected conditions without failure, ensuring a high level of trust from users and stakeholders. However, improving reliability often involves trade-offs in system complexity, cost, and development time.

容错性

Fault tolerance

关键可靠性的一个方面是确保代理程序能够处理错误或意外事件，而不会崩溃或出现不可预测的行为。这可能涉及构建容错机制，使代理程序能够检测到故障（例如网络中断、硬件故障）并优雅地恢复。容错系统通常采用冗余设计——复制关键组件或进程，以确保系统某一部分的故障不会影响整体性能。

One key aspect of reliability is ensuring that agents can handle errors or unexpected events without crashing or behaving unpredictably. This may involve building in fault tolerance, where the agent can detect failures (e.g., network interruptions, hardware failures) and recover gracefully. Fault-tolerant systems often employ redundancy—duplicating critical components or processes to ensure that failures in one part of the system do not affect overall performance.

一致性和稳健性

Consistency and robustness

为了确保智能体的可靠性，它们必须在不同的场景、输入和环境下都能保持一致的性能。这一点在安全攸关的系统中尤为重要，例如自动驾驶汽车或医疗保健智能体，因为任何错误都可能造成严重后果。开发人员必须确保智能体不仅在理想条件下表现良好，而且在极端情况、压力测试和实际环境约束下也能有效运行。实现可靠性需要：

For agents to be reliable, they must perform consistently across different scenarios, inputs, and environments. This is particularly important in safety-critical systems, such as autonomous vehicles or healthcare agents, where a mistake could have serious consequences. Developers must ensure that the agent performs well not only in ideal conditions but also under edge cases, stress tests, and real-world constraints. Achieving reliability requires:

广泛测试

Extensive testing

代理人应经过严格的测试，包括单元测试、集成测试和真实场景模拟。测试应涵盖极端情况、意外输入和对抗性条件，以确保智能体能够应对各种不同的环境。

Agents should undergo rigorous testing, including unit tests, integration tests, and simulations of real-world scenarios. Tests should cover edge cases, unexpected inputs, and adversarial conditions to ensure that the agent can handle diverse environments.

监控和反馈回路

Monitoring and feedback loops

可靠的在生产环境中，智能体需要持续监控，以便检测异常情况并根据不断变化的环境调整自身行为。反馈回路使智能体能够从环境中学习，并随着时间的推移提高性能，从而增强其应用能力。鲁棒性。

Reliable agents require continuous monitoring in production to detect anomalies and adjust their behavior in response to changing conditions. Feedback loops enable agents to learn from their environment and improve performance over time, increasing their robustness.

成本：平衡绩效与支出

Costs: Balancing Performance and Expense

成本是在基于代理的系统设计中，成本权衡往往被忽视，但却至关重要。开发、部署和维护代理的相关成本必须与预期收益和投资回报率 (ROI) 进行权衡。成本考量会影响与模型复杂性、基础设施和可扩展性相关的决策。

Cost is an often-overlooked but critical trade-off in the design of agent-based systems. The costs associated with developing, deploying, and maintaining an agent must be weighed against the expected benefits and return on investment (ROI). Cost considerations affect decisions related to model complexity, infrastructure, and scalability.

开发成本

Development costs

发展复杂的智能体可能成本高昂，尤其是在使用高级机器学习 (ML) 模型时，这些模型需要庞大的数据集、专业知识和大量的计算资源进行训练。此外，迭代设计、测试和优化的需求也会增加开发成本。

Developing sophisticated agents can be expensive, especially when using advanced machine learning (ML) models that require large datasets, specialized expertise, and significant computational resources for training. Additionally, the need for iterative design, testing, and optimization increases development costs.

复杂的智能体通常需要一个由数据科学家、机器学习工程师和领域专家等专业人员组成的团队来构建高性能系统。此外，构建可靠且可扩展的智能体系统需要完善的测试基础设施，通常涉及仿真环境以及对测试工具和框架的投资，以确保系统的稳健性。

Complex agents frequently necessitate a team with specialized talent, including data scientists, ML engineers, and domain experts, to create high-performing systems. Additionally, building a reliable and scalable agent system requires extensive testing infrastructure, often involving simulation environments and investments in testing tools and frameworks to ensure robust functionality.

运营成本

Operational costs

后部署过程中，运行代理的运营成本可能相当高昂，尤其对于需要强大计算能力的系统而言，例如涉及实时决策或连续数据处理的系统。造成这些成本的主要原因之一是需要大量的计算能力，因为运行深度学习模型或复杂算法的代理通常依赖于昂贵的硬件，例如 GPU 或云服务。

After deployment, the operational costs of running agents can become substantial, particularly for systems requiring high computational power, such as those involving real-time decision making or continuous data processing. Key contributors to these expenses include the need for significant compute power, as agents running deep learning models or complex algorithms often rely on costly hardware like GPUs or cloud services.

此外，处理海量数据或维护大量记忆的代理程序会产生更高的数据存储和带宽成本。定期维护和更新（包括漏洞修复和系统改进）也会增加运营成本，因为需要投入资源来确保系统长期的可靠性和性能。

Additionally, agents that process vast amounts of data or maintain extensive memory incur higher costs for data storage and bandwidth. Regular maintenance and updates, including bug fixes and system improvements, further add to operational expenses as resources are needed to ensure the system’s reliability and performance over time.

成本与价值

Cost versus value

最终，基于代理的系统的成本必须与其带来的价值相匹配。在某些情况下，对于不太重要的任务，优先选择成本更低、更简单的代理可能更为合理；而对于关键任务应用，则应大力投资开发更复杂的代理。成本决策必须结合系统的总体目标和预期寿命来制定。一些优化策略包括：

Ultimately, the cost of an agent-based system must be justified by the value it delivers. In some cases, it may make sense to prioritize cheaper, simpler agents for less critical tasks, while investing heavily in more sophisticated agents for mission-critical applications. Decisions around cost must be made in the context of the system’s overall goals and expected lifespan. Some optimization strategies include:

精益模型

Lean models

在适当情况下使用更简单、更高效的模型有助于降低开发和运营成本。例如，如果基于规则的系统能够为特定任务取得与深度学习模型类似的结果，那么更简单的方法通常会更具成本效益。

Using simpler, more efficient models where appropriate can help reduce both development and operational costs. For example, if a rule-based system can achieve similar results to a deep learning model for a given task, the simpler approach will often be more cost-effective.

云资源

Cloud-based resources

利用云计算资源可以降低前期基础设施成本，建立更具可扩展性的按需付费模式。

Leveraging cloud computing resources can reduce up-front infrastructure costs, establishing a more scalable, pay-as-you-go model.

开源模型和工具

Open source models and tools

利用开源机器学习库和框架可以帮助最大限度地降低软件开发成本，同时还能提供高质量的代理。

Utilizing open source ML libraries and frameworks can help minimize software development costs while still delivering high-quality agents.

设计智能体系统需要在几个关键方面进行权衡。优先考虑性能可能需要牺牲一些精度，而扩展到多智能体架构则会带来协调性和一致性方面的挑战。确保可靠性需要严格的测试和监控，但这会增加开发时间和复杂性。最后，必须从开发和运营两个角度考虑成本，确保系统在预算范围内创造价值。在下一节中，我们将回顾一些构建高效智能体系统时最常用的设计模式。智能体系统。

Designing agent systems involves balancing several critical trade-offs. Prioritizing performance may require sacrificing some accuracy, while scaling to a multiagent architecture introduces challenges in coordination and consistency. Ensuring reliability demands rigorous testing and monitoring but can increase development time and complexity. Finally, cost considerations must be factored in from both a development and operational perspective, ensuring that the system delivers value within budget constraints. In the next section, we’ll review some of the most common design patterns used when building effective agentic systems.

单代理架构

Single-Agent Architectures

单代理架构这是最简单直接的设计之一，其中单个代理负责管理和执行系统内的所有任务。该代理直接与环境交互，独立处理决策、规划和执行，无需依赖其他代理。

A single-agent architecture is among the simplest and most straightforward designs, where a single agent is responsible for managing and executing all tasks within a system. This agent interacts directly with its environment and independently handles decision making, planning, and execution without relying on other agents.

这种架构非常适合定义明确、范围狭窄的任务，尤其适合由单个实体管理的工作负载。单代理系统的简洁性使其易于设计、开发和部署，因为它避免了跨多个组件的协调、通信和同步等复杂性。对于用例清晰的单代理架构，它们在无需协作或分布式处理的窄范围任务中表现出色，例如处理基本客户查询（如常见问题解答和订单跟踪）的简单聊天机器人，以及用于数据录入或文件管理的特定任务自动化。

Ideal for well-defined and narrow tasks, this architecture is best suited for workloads that are manageable by a single entity. The simplicity of single-agent systems makes them easy to design, develop, and deploy, as they avoid complexities related to coordination, communication, and synchronization across multiple components. With clear use cases, single-agent architectures excel in narrow-scope tasks that do not require collaboration or distributed efforts, such as simple chatbots handling basic customer queries (like FAQs and order tracking) and task-specific automation for data entry or file management.

单代理架构适用于问题领域定义明确、任务简单明了且无需大幅扩展的环境。这使得它们非常适合客户服务聊天机器人、通用助手和代码生成代理。我们将在第 8 章更详细地讨论单代理和多代理架构。

Single-agent setups work well in environments where the problem domain is well-defined, tasks are straightforward, and there is no significant need for scaling. This makes them a fit for customer service chatbots, general-purpose assistants, and code generation agents. We’ll discuss single-agent and multiagent architectures much more in Chapter 8.

多智能体架构：协作、并行和协调

Multiagent Architectures: Collaboration, Parallelism, and Coordination

在多智能体中在多智能体架构中，多个智能体协同工作以实现共同目标。这些智能体可以独立运行、并行运行或协同工作，具体取决于任务的性质。多智能体系统常用于复杂的环境中，在这些环境中，任务的不同方面需要由专门的智能体进行管理，或者并行处理可以提高效率和可扩展性，并且多智能体系统具有诸多优势：

In multiagent architectures, multiple agents work together to achieve a common goal. These agents may operate independently, in parallel, or through coordinated efforts, depending on the nature of the tasks. Multiagent systems are often used in complex environments where different aspects of a task need to be managed by specialized agents or where parallel processing can improve efficiency and scalability, and they bring many advantages:

协作与专业化

Collaboration and specialization

在多智能体系统中，每个智能体都可以被设计成专门负责特定的任务或领域。例如，一个智能体可以专注于数据收集，另一个智能体负责数据处理，而第三个智能体则负责管理用户交互。这种分工使得系统能够比单个智能体更高效地处理复杂任务。

Each agent in a multiagent system can be designed to specialize in specific tasks or areas. For example, one agent may focus on data collection while another processes the data, and a third agent manages user interactions. This division of labor enables the system to handle complex tasks more efficiently than a single agent would.

平行结构

Parallelism

多智能体架构可以利用并行性同时执行多个任务。例如，物流系统中的智能体可以同时规划不同的配送路线，从而减少整体处理时间并提高效率。

Multiagent architectures can leverage parallelism to perform multiple tasks simultaneously. For instance, agents in a logistics system can simultaneously plan different delivery routes, reducing overall processing time and improving efficiency.

提高可扩展性

Improved scalability

随着系统规模的扩大，可以引入更多智能体来处理更多任务或分担工作负载。这使得多智能体系统具有高度可扩展性，能够管理更大、更复杂的环境。

As the system grows, additional agents can be introduced to handle more tasks or to distribute the workload. This makes multiagent systems highly scalable and capable of managing larger and more complex environments.

冗余和弹性

Redundancy and resilience

由于多个智能体独立运行，一个智能体的故障并不一定会危及整个系统。其他智能体可以继续运行，甚至可以接管故障智能体的职责，从而改善系统性能。系统整体可靠性。

Because multiple agents operate independently, failure in one agent does not necessarily compromise the entire system. Other agents can continue to function or even take over the failed agent’s responsibilities, improving overall system reliability.

尽管多智能体系统具有这些优势，但它们也面临着巨大的挑战，这些挑战包括：包括：

Despite these advantages, multiagent systems also come with significant challenges, which include:

协调与沟通

Coordination and communication

管理智能体之间的通信可能非常复杂。智能体必须高效地交换信息并协调行动，以避免重复劳动、行动冲突或资源争用。如果没有适当的协调，多智能体系统可能会变得混乱且效率低下。

Managing communication between agents can be complex. Agents must exchange information efficiently and coordinate their actions to avoid duplication of efforts, conflicting actions, or resource contention. Without proper orchestration, multiagent systems can become disorganized and inefficient.

复杂性增加

Increased complexity

多智能体系统虽然功能强大，但其设计、开发和维护也更具挑战性。通信协议、协调策略和同步机制的需求，都为系统架构增加了复杂性。

While multiagent systems are powerful, they are also more challenging to design, develop, and maintain. The need for communication protocols, coordination strategies, and synchronization mechanisms adds layers of complexity to the system architecture.

效率较低

Lower efficiency

虽然并非总是如此，但多智能体系统在完成任务时，由于令牌消耗量较高，效率往往会降低。这是因为智能体必须频繁通信、共享上下文信息并协调行动，因此与单智能体系统相比，它们会消耗更多的处理能力和资源。令牌使用量的增加不仅会导致更高的计算成本，而且如果通信和协调没有得到优化，还会减慢任务完成速度。因此，尽管多智能体系统为复杂任务提供了强大的解决方案，但其效率方面的挑战意味着谨慎的资源管理至关重要。

While not always the case, multiagent systems often encounter reduced efficiency due to higher token consumption when completing tasks. Because agents must frequently communicate, share context, and coordinate actions, they consume more processing power and resources compared with single-agent systems. This increased token usage not only leads to higher computational costs but can also slow task completion if communication and coordination are not optimized. Consequently, while multiagent systems offer robust solutions for complex tasks, their efficiency challenges mean that careful resource management is crucial.

多智能体架构非常适合任务复杂、分散或需要不同组件间专业化的环境。在这些系统中，多个智能体共同协作解决复杂的分布式问题，例如金融交易系统、网络安全调查或协作式人工智能研究平台。

Multiagent architectures are well suited for environments where tasks are complex, distributed, or require specialization across different components. In these systems, multiple agents contribute to solving complex, distributed problems, such as in financial trading systems, cybersecurity investigations, or collaborative AI research platforms.

单智能体系统简单易用，非常适合处理定义明确的任务。多智能体系统则具备协作、并行和可扩展性，使其更适合复杂的环境。选择合适的架构取决于任务的复杂性、可扩展性需求以及系统的预期寿命。下一节我们将讨论一些原则，以帮助我们获得最佳的架构效果。我们构建的智能体系统。

Single-agent systems offer simplicity and are ideal for well-defined tasks. Multiagent systems provide collaboration, parallelism, and scalability, making them suitable for complex environments. Choosing the right architecture depends on the complexity of the task, the need for scalability, and the expected lifespan of the system. In the next section, we’ll discuss some principles we can follow to get the best results from the agentic systems we build.

迭代设计

Iterative Design

迭代设计是一种迭代设计是智能体开发的基本方法，强调在不断融入反馈的同时，逐步构建系统。它并不追求在初始构建阶段就达到完美，而是专注于创建小型、功能齐全的原型，并在多个迭代周期中进行评估、改进和完善。这一过程能够快速识别缺陷、迅速纠正方向并持续改进系统，并具有以下多重优势：

Iterative design is a fundamental approach in agent development, emphasizing the importance of building systems incrementally while continually incorporating feedback. Instead of aiming for a perfect solution in the initial build, iterative design focuses on creating small, functional prototypes that you can evaluate, improve, and refine over multiple cycles. This process allows for quick identification of flaws, rapid course correction, and continuous system improvement, and it has multiple benefits:

及早发现问题

Early detection of issues

通过发布早期原型，开发人员可以在设计缺陷或性能瓶颈深入系统之前将其识别出来。这有助于快速修复问题，降低长期开发成本，并避免重大重构。

By releasing early prototypes, developers can identify design flaws or performance bottlenecks before they become deeply embedded in the system. This enables swift remediation of issues, reducing long-term development costs and avoiding major refactors.

以用户为中心的设计

User-centric design

迭代设计鼓励利益相关者、最终用户和其他开发人员频繁提供反馈。这些反馈确保代理系统始终符合用户的需求和期望。随着代理在真实场景中接受测试，迭代改进可以微调其行为和响应，使其更好地满足用户需求。

Iterative design encourages frequent feedback from stakeholders, end users, and other developers. This feedback ensures that the agent system remains aligned with the users’ needs and expectations. As agents are tested in real-world scenarios, iterative improvements can fine-tune their behaviors and responses to better suit the users they serve.

可扩展性

Scalability

从最小可行产品 (MVP) 或基础代理入手，可以让系统以可控的增量逐步发展和演进。随着系统的成熟，可以逐步引入新的特性和功能，确保每次新增功能在全面部署前都经过充分测试。

Starting with a minimal viable product (MVP) or basic agent enables the system to grow and evolve in manageable increments. As the system matures, new features and capabilities can be introduced gradually, ensuring that each addition is thoroughly tested before full deployment.

为了有效地采用迭代设计，开发团队应该：

To adopt iterative design effectively, development teams should:

快速开发原型

Develop prototypes quickly

首先专注于构建核心功能。现阶段不要追求完美——即使功能比较基础，也要构建出能够运行并带来价值的东西。

Focus on building core functionality first. Don’t aim for perfection at this stage—build something that works and delivers value, even if it’s basic.

测试并收集反馈

Test and gather feedback

每次迭代后，收集用户、开发者和其他利益相关者的反馈。利用这些反馈来指导改进工作，并确定下一次迭代的优先事项。

After each iteration, collect feedback from users, developers, and other stakeholders. Use this feedback to guide improvements and decide on the next iteration’s priorities.

改进并重复

Refine and repeat

根据反馈和性能数据，在下一次迭代中进行必要的更改并改进系统。重复此循环，直到代理系统达到其性能、可用​​性和可扩展性目标。

Based on feedback and performance data, make necessary changes and refine the system in the next iteration. Continue this cycle until the agent system meets its performance, usability, and scalability goals.

有效的迭代设计包括快速开发功能原型，在每次迭代后收集反馈，并根据这些反馈不断改进系统，以满足性能要求。以及可用性目标。

Effective iterative design involves quickly developing functional prototypes, gathering feedback after each iteration, and continuously refining the system based on insights to meet performance and usability goals.

评估策略

Evaluation Strategy

评估基于代理的系统的性能和可靠性是开发过程中至关重要的环节。稳健的评估能够确保代理可以处理真实场景，在各种条件下运行，并满足性能预期。这需要采用系统的方法，从准确性、效率、鲁棒性和可扩展性等不同维度对代理进行测试和验证。本节将探讨构建代理系统综合评估框架的关键策略。我们将在第9章更深入地讨论测量和验证。

Evaluating the performance and reliability of agent-based systems is a critical part of the development process. A robust evaluation ensures that agents are capable of handling real-world scenarios, performing under varying conditions, and meeting performance expectations. It involves a systematic approach to testing and validating agents across different dimensions, including accuracy, efficiency, robustness, and scalability. This section explores key strategies for creating a comprehensive evaluation framework for agent systems. We’ll cover measurement and validation in far more depth in Chapter 9.

一个完善的评估流程包括开发一个涵盖智能体所有功能的全面测试框架。该框架确保智能体在各种预期和非预期场景下都得到彻底测试。

A robust evaluation process involves developing a comprehensive testing framework that covers all aspects of the agent’s functionality. This framework ensures that the agent is thoroughly tested under a variety of scenarios, both expected and unexpected.

功能测试侧重于验证智能体是否正确执行其核心任务。智能体的每个技能或模块都应单独测试，以确保其在不同的输入和场景下都能按预期运行。重点关注领域包括：

Functional testing focuses on verifying that the agent performs its core tasks correctly. Each skill or module of the agent should be individually tested to ensure that it behaves as expected across different inputs and scenarios. Key areas of focus include:

正确性

Correctness

确保代理始终根据其设计提供准确且符合预期的输出。

Ensuring that the agent consistently delivers accurate and expected outputs based on its design

边界测试

Boundary testing

评估代理如何处理极端情况和极端输入，例如非常大的数据集、不寻常的查询或含糊不清的指令。

Evaluating how the agent handles edge cases and extreme inputs, such as very large datasets, unusual queries, or ambiguous instructions

特定任务指标

Task-specific metrics

对于处理特定领域任务（例如，法律分析、医疗诊断）的代理而言，确保系统满足以下要求至关重要：域名准确性和合规性要求

For agents handling domain-specific tasks (e.g., legal analysis, medical diagnostics), ensuring the system meets the domain’s accuracy and compliance requirements

为了对于智能体系统，尤其是那些由机器学习模型驱动的系统而言，评估智能体在特定训练场景之外的泛化能力至关重要。这可以确保智能体在处理新的、未曾见过的情况时，仍能保持准确性和可靠性。

For agent systems, particularly those powered by ML models, it is essential to evaluate the agent’s ability to generalize beyond the specific scenarios it was trained on. This ensures the agent can handle new, unseen situations while maintaining accuracy and reliability.

智能体经常会遇到超出其原始训练领域范围的任务。一个有效的评估应该测试智能体在无需大量重新训练的情况下适应这些新任务的能力。这对于通用智能体或设计用于动态环境的智能体尤为重要。

Agents often encounter tasks outside of their original training domain. A robust evaluation should test the agent’s ability to adapt to these new tasks without requiring extensive retraining. This is particularly important for general-purpose agents or those designed to operate in dynamic environments.

用户体验这是决定代理系统成功与否的关键因素。评估代理的技术性能固然重要，但更重要的是评估其在实际应用中满足用户期望的程度。

User experience is a key factor in determining the success of agent systems. It’s important to evaluate not only the technical performance of the agent but also how well it meets user expectations in real-world applications.

收集真实用户的反馈能够提供关于智能体在实际应用中表现的关键信息。这些反馈有助于改进智能体的行为，提高其有效性和用户满意度，反馈内容可以包括以下几个方面：

Collecting feedback from actual users provides critical insights into how well the agent performs in practice. This feedback helps refine the agent’s behaviors, improving its effectiveness and user satisfaction, and can consist of the following:

用户满意度评分

User satisfaction scores

使用净推荐值 (NPS) 或客户满意度 (CSAT) 等指标来衡量用户对与客服人员互动的感受。

Use metrics like net promoter score (NPS) or customer satisfaction (CSAT) to gauge how users feel about their interactions with the agent.

任务完成率

Task completion rates

衡量用户在代理的帮助下成功完成任务的频率。完成率低可能表明用户感到困惑或代理设计存在效率低下的问题。

Measure how often users successfully complete tasks with the agent’s help. Low completion rates may indicate confusion or inefficiencies in the agent’s design.

显式信号

Explicit signals

创造机会让用户提供反馈，例如点赞、踩、星级评分，以及根据具体情况接受、拒绝或修改生成结果。这些反馈信号可以提供丰富的洞察。

Create opportunities for users to provide their feedback, in such forms as thumbs-up and thumbs-down, star ratings, and the ability to accept, reject, or modify the generated results, depending on the context. These signals can provide a wealth of insight.

隐含信号

Implicit signals

分析用户与代理的交互，以识别常见的故障点，例如误解、延迟、情绪偏差或不恰当的响应。可以挖掘交互日志，以了解代理需要改进的方面。

Analyze user-agent interactions to identify common points of failure, such as misinterpretations, delays, sentiment, or inappropriate responses. Interaction logs can be mined for insights into areas where the agent needs improvement.

在某些情况下，为了评估智能体的决策准确性，必须让人类专家参与评估过程。人机协同验证将自动化评估与人类判断相结合，确保智能体的性能符合现实世界的标准。在条件允许的情况下，应由人类专家审查智能体输出样本，以验证其正确性、伦理合规性和与最佳实践的一致性。这些审查结果可用于校准和改进自动化评估。

In some cases, it’s necessary to involve human experts in the evaluation process to assess the agent’s decision-making accuracy. Human-in-the-loop validation combines automated evaluation with human judgment, ensuring that the agent’s performance aligns with real-world standards. When feasible, human experts should review a sample of the agent’s outputs to verify correctness, ethical compliance, and alignment with best practices, and these reviews can then be used to calibrate and improve automated evaluations.

我们应该在能够高度模拟实际应用场景的环境中评估智能体。这有助于确保系统在受控开发环境之外也能可靠运行。 评估智能体时，应涵盖其运行环境的各个方面，从数据摄取和处理到任务执行和输出生成。端到端测试能够确保智能体在多个系统、数据源和平台上都能按预期运行。

We should evaluate agents in environments that closely simulate their real-world applications. This helps ensure that the system can perform reliably outside of controlled development conditions. Evaluate the agent across the full spectrum of its operational environment, from data ingestion and processing to task execution and output generation. End-to-end testing ensures that the agent functions as expected across multiple systems, data sources, and platforms.

实际测试

Real-World Testing

在建造过程中在受控的开发环境中进行代理测试对于初始测试至关重要，但同样重要的是在真实环境中验证代理，以确保它们在与真实用户或环境交互时能够按预期运行。真实环境测试是指将代理部署到实际生产环境中，并观察它们在真实条件下的行为。这一阶段的测试使开发人员能够发现早期开发阶段可能未出现的问题，并评估代理的健壮性、可靠性和对用户的影响。

While building agents in a controlled development environment is crucial for initial testing, it’s equally important to validate agents in real-world settings to ensure they perform as expected when interacting with live users or environments. Real-world testing involves deploying agents in actual production environments and observing their behavior under real-life conditions. This stage of testing enables developers to uncover issues that may not have surfaced during earlier development stages and to evaluate the agent’s robustness, reliability, and user impact.

真实环境测试对于确保智能体能够应对实时环境的不可预测性和复杂性至关重要。与受控测试不同，这种方法能够揭示极端情况、意外的用户输入以及高需求下的性能，从而帮助开发人员改进智能体，使其能够稳健可靠地运行：

Real-world testing is essential for ensuring agents can manage the unpredictability and complexity of live environments. Unlike controlled testing, this approach reveals edge cases, unexpected user inputs, and performance under high demand, helping developers refine the agent for robust, reliable operation:

接触现实世界的复杂性

Exposure to real-world complexity

在受控环境中，智能体基于可预测的输入和响应运行。然而，现实世界环境是动态且不可预测的，包含各种用户、极端情况和无法预见的挑战。在这些环境中进行测试可以确保智能体能够应对现实世界场景的复杂性和多变性。

In controlled environments, agents operate with predictable inputs and responses. However, real-world environments are dynamic and unpredictable, with diverse users, edge cases, and unforeseen challenges. Testing in these environments ensures that the agent can handle the complexity and variability of real-world scenarios.

发现极端情况

Uncovering edge cases

实际交互中常常会暴露出一些在设计或测试阶段可能未考虑到的特殊情况。例如，一个使用脚本查询进行测试的聊天机器人可能在开发阶段表现良好，但当面对真实用户时，它可能难以应对意外的输入、含糊不清的问题或自然语言的各种变体。

Real-world interactions often expose edge cases that may not have been accounted for in the design or testing phases. For example, a chatbot tested with scripted queries might perform well in development, but when exposed to real users, it may struggle with unexpected inputs, ambiguous questions, or natural language variations.

评估负载下的性能

Evaluating performance under load

实际环境测试还能让开发者观察代理在高负载或用户需求增加的情况下表现如何。这对于在流量波动较大的环境中运行的代理（例如客服机器人或电商推荐引擎）尤为重要。

Real-world testing also enables developers to observe how the agent performs under high workloads or increased user demand. This is particularly important for agents that operate in environments with fluctuating traffic, such as customer service bots or ecommerce recommendation engines.

真实世界的测试确保代理做好应对准备通过在实际环境中验证其性能来进行部署。此过程包括分阶段推出、持续监控关键指标、收集用户反馈，并迭代改进代理，以优化其功能和可用性：

Real-world testing ensures an agent’s readiness for deployment by validating its performance under real-life conditions. This process involves a phased rollout, continuous monitoring of key metrics, collecting user feedback, and iteratively refining the agent to optimize its capabilities and usability:

分阶段部署

Deploy in phases

分阶段推出代理程序，首先在有限的环境中进行小规模测试，然后再逐步扩大规模进行全面部署。这种分阶段的方法有助于逐步发现和解决问题，而不会给系统或用户造成过大的压力。

Roll out the agent in stages, starting with small-scale testing in a limited environment before scaling up to full deployment. This phased approach helps identify and address issues incrementally, without overwhelming the system or users.

监控代理行为

Monitor agent behavior

在实际测试过程中，使用监控工具跟踪代理的行为、响应和性能指标。监控应重点关注关键性能指标 (KPI)，例如响应时间、准确率、用户满意度和系统稳定性。

Use monitoring tools to track the agent’s behavior, responses, and performance metrics during real-world testing. Monitoring should focus on key performance indicators (KPIs) such as response time, accuracy, user satisfaction, and system stability.

收集用户反馈

Collect user feedback

在实际测试过程中，要让用户参与进来，收集他们与智能体交互时的体验反馈。用户反馈对于发现不足、提升可用性以及确保智能体满足实际需求至关重要。

Engage users during real-world testing to gather feedback on their experiences when interacting with the agent. User feedback is invaluable in identifying gaps, improving usability, and ensuring that the agent meets real-world needs.

根据洞察不断迭代

Iterate based on insights

真实世界的测试能够提供宝贵的见解，这些见解应该反馈到开发周期中。利用这些见解来改进代理，提升其功能，并优化其性能，以用于未来的迭代。

Real-world testing provides valuable insights that should be fed back into the development cycle. Use these insights to refine the agent, improve its capabilities, and optimize its performance for future iterations.

遵循迭代设计、敏捷开发和真实环境测试等最佳实践，对于构建适应性强、可扩展且具有弹性的基于代理的系统至关重要。这些实践确保代理在设计时具有灵活性，在真实环境条件下经过全面测试，并持续改进以满足不断变化的用户需求和环境挑战。通过将这些方法融入开发生命周期，开发人员可以创建更可靠、更高效、更有效的代理。能够在动态环境中蓬勃发展的系统。

Following best practices such as iterative design, agile development, and real-world testing is critical for building agent-based systems that are adaptable, scalable, and resilient. These practices ensure that agents are designed with flexibility, thoroughly tested in real-world conditions, and continuously improved to meet evolving user needs and environmental challenges. By incorporating these approaches into the development lifecycle, developers can create more reliable, efficient, and effective agent systems capable of thriving in dynamic environments.

图形界面

Graphical Interfaces

图形界面为用户提供了一种可视化和交互式的方式来与代理系统互动，它结合了文本、按钮、图标和其他图形元素，以促进沟通。这些界面对于需要清晰视觉效果、结构化工作流程或多步骤流程的任务尤为有效，因为纯文本或语音交互可能难以满足这些需求。常见的例子包括基于仪表盘的人工智能工具、图形化聊天界面以及带有可点击元素的代理驱动型生产力平台。

Graphical interfaces offer users a visual and interactive way to engage with agent systems, combining text, buttons, icons, and other graphical elements to facilitate communication. These interfaces are particularly effective for tasks requiring visual clarity, structured workflows, or multistep processes, where pure text or voice interactions may fall short. Common examples include dashboard-based AI tools, graphical chat interfaces, and agent-powered productivity platforms with clickable elements.

图形界面的主要优势在于其能够以可视化的方式呈现信息并降低认知负荷。人类主要依赖视觉输入，处理视觉信息的速度和便捷性远胜于处理文本信息。精心设计的界面能够以直观易懂的方式展示复杂数据、状态更新或任务进度。进度条、颜色编码和提示图标等视觉提示能够有效地引导用户，而无需冗长的解释。

The key strength of graphical interfaces lies in their ability to present information visually and reduce cognitive load. Humans primarily rely on visual input and can process visual information more quickly and easily than text-based information. Well-designed interfaces can display complex data, status updates, or task progress in an intuitive and digestible format. Visual cues, such as progress bars, color coding, and alert icons, guide users effectively without requiring lengthy explanations.

例如，管理工作流程的代理可以使用仪表板来显示待处理任务、已完成步骤和错误通知，使用户能够快速了解​​系统状态。LangSmith、n8n、Arize 和 AutoGen 等工具正开始展示这一功能。通过可视化方式呈现代理工作流，可以更轻松地理解、调试和分析它们；未来我们很可能会看到更多此类可视化编排方式。为了展示这些图形化编排界面在实践中的应用，图 3-2展示了一个现代代理工作流构建器的示例。这类工具将代理操作、工具调用、条件语句和输出以连接的可视化节点形式呈现，使开发人员和运维人员能够轻松理解、调试和优化复杂的代理流程，而无需单独查看原始代码。

For example, an agent managing a workflow might use a dashboard to show pending tasks, completed steps, and error notifications, enabling users to quickly understand the system’s state at a glance. Tools like LangSmith, n8n, Arize, and AutoGen are beginning to illustrate agent workflows visually, making them easier to understand, debug, and reason about; we are likely to see much more of this visual orchestration in the future. To see how these graphical orchestration interfaces are emerging in practice, Figure 3-2 shows an example of a modern agent workflow builder. Tools like this illustrate agent actions, tool calls, conditionals, and outputs as connected visual nodes, enabling developers and operators to easily understand, debug, and optimize complex agentic flows without stepping through raw code alone.

图 3-2. n8n.io 中代理工作流的可视化编排。该界面展示了一个 AI 代理，它集成了多个工具、模型和结构化解析组件，并以基于节点的工作流形式排列。这种可视化设计使得大规模构建、管理和迭代多步骤代理管道变得更加容易。

类似地，图 3-3展示了一个现代化的 AI 赋能型 IDE 界面，类似于 Cursor、Windsurf、Cline 等工具。这些环境将自然语言理解直接集成到编码工作流程中，使开发人员能够在单一、简洁的图形界面中提出问题、生成代码、重构函数并获得解释或性能优化建议。

Similarly, Figure 3-3 shows a modern AI-enabled IDE interface, similar to tools like Cursor, Windsurf, Cline, and many more. These environments integrate natural language understanding directly into the coding workflow, enabling developers to ask questions, generate code, refactor functions, and receive explanations or performance optimizations—all within a single, streamlined graphical interface.

图 3-3.人工智能赋能的 IDE 界面。集成开发环境 (IDE) 增强了人工智能功能，将传统的文件资源管理器和代码编辑器与自然语言助手面板相结合，提供解释、调试建议和自动生成的代码改进。

这些例子共同展现了图形化智能用户体验的快速发展。随着这些界面日趋成熟，它们将重新定义高效的、人工智能赋能的工具——不仅对开发者而言如此，对所有人来说也是如此。知识密集型职业。

Together, these examples illustrate the rapid evolution of graphical agentic UX. As these interfaces mature, they will redefine what productive, AI-enabled tools look like—not just for developers, but for every knowledge-intensive profession.

不断扩展的前沿图形代理界面领域正在涌现出生成式用户界面。生成式用户界面不再仅仅依赖静态仪表盘或预设布局，而是根据用户查询动态创建界面元素、数据可视化或结构化输出。例如，Perplexity AI 不仅提供文本答案，还能生成与用户问题相匹配的结构化知识卡、参考列表和数据表。同样，AI 编码助手也能根据用户意图生成完整的表单、配置文件或用户界面组件。

A growing frontier in graphical agent interfaces is the emergence of generative UIs. Instead of relying solely on static dashboards or predesigned layouts, generative UIs dynamically create interface elements, data visualizations, or structured outputs based on user queries. For example, Perplexity AI not only provides textual answers but also generates structured knowledge cards, reference lists, and data tables tailored to the question asked. Similarly, AI coding copilots generate entire forms, config files, or UI components based on user intent.

生成式用户界面结合了自然语言的灵活性和图形布局的清晰易懂性，使智能体能够按需创建丰富的、特定于上下文的界面。这扩展了图形智能体的应用范围，使其从预定义的工作流程扩展到开放式任务，在这些任务中，视觉结构有助于增强理解。然而，设计生成式用户界面也带来了新的挑战：如何确保生成的元素可用且美观，同时避免信息过载或组织混乱，从而避免用户感到不知所措。精心设计的模式、布局约束和优先级逻辑对于保持生成式用户界面的有效性和用户友好性至关重要。

Generative UIs combine the flexibility of natural language with the clarity and discoverability of graphical layouts, enabling agents to create rich, context-specific interfaces on demand. This expands the usefulness of graphical agents from predefined workflows to open-ended tasks where visual structuring enhances understanding. However, designing generative UIs introduces new challenges: ensuring the generated elements are usable and aesthetically coherent, and that they do not overwhelm users with poorly organized or excessive information. Careful design patterns, layout constraints, and prioritization logic are critical to keep generative UIs effective and user-friendly.

设计高效的图形代理界面也面临着一些传统挑战。屏幕空间有限，因此需要对显示信息进行优先级排序，以确保关键细节不会被杂乱的信息淹没。代理必须保证界面的响应速度——用户期望实时更新和状态间的流畅过渡，尤其是在代理异步运行的情况下。此外，图形元素必须能够优雅地适应不同的设备和屏幕尺寸，确保无论是在台式机、平板电脑还是手机上查看，都能保持一致的视觉效果。

Designing effective graphical agent interfaces also comes with traditional challenges. Screen real estate is limited, requiring prioritization of displayed information to ensure critical details are not buried in clutter. Agents must manage interface responsiveness—users expect real-time updates and smooth transitions between states, especially when agents operate asynchronously. Additionally, graphical elements must adapt gracefully across devices and screen sizes, ensuring consistency whether viewed on a desktop, tablet, or mobile phone.

另一个关键考虑因素是自动化和用户控制之间的平衡。图形界面通常会将代理的自主性与用户驱动的操作相结合，例如批准代理建议的决策或手动覆盖建议。例如，代理建议更改日历时，可能会通过按钮显示多个选项，使用户能够以清晰高效的方式做出最终决定。

Another critical consideration is the balance between automation and user control. Graphical interfaces often blend agent autonomy with user-driven actions, such as approving agent-suggested decisions or manually overriding recommendations. For example, an agent suggesting a calendar change might display multiple options through buttons, giving users a clear and efficient way to make a final decision.

图形界面在数据可视化、结构化交互和清晰的状态更新至关重要的应用场景中表现出色。例如，任务管理仪表盘、由人工智能代理驱动的数据分析工具、带有筛选器和可视化预览的电商产品推荐系统，以及能够根据用户问题动态生成结构化输出的生成式用户界面系统。它们在混合工作流程中尤为有效，在这些工作流程中，代理在后台运行，但会以可视化的方式呈现更新或选项以供用户确认。

Graphical interfaces excel in use cases where data visualization, structured interactions, and clear status updates are essential. Examples include task management dashboards, data analytics tools powered by AI agents, ecommerce product recommendation systems with filters and visual previews, and generative UI systems that dynamically produce structured outputs tailored to user questions. They are particularly effective in hybrid workflows where agents operate in the background but present updates or options visually for user confirmation.

精心设计的图形化和生成式界面能够实现与智能体的清晰、高效且令人满意的交互。它们减少了歧义，提高了任务清晰度，并赋予用户切实的控制感。通过关注清晰度、响应速度、直观的设计模式以及生成式用户界面功能的潜力，图形化界面确保了与智能体的交互流畅、透明且符合预期。用户期望。

When implemented thoughtfully, graphical and generative interfaces enable clear, efficient, and satisfying interactions with agents. They reduce ambiguity, improve task clarity, and offer users a tangible sense of control. By focusing on clarity, responsiveness, intuitive design patterns, and the emerging potential of generative UI capabilities, graphical interfaces ensure that agent interactions feel smooth, transparent, and aligned with user expectations.

图形界面在数据可视化、结构化交互和清晰的状态更新至关重要的应用场景中表现出色。近年来，Lovable、Cursor、Windsurf 和 GitHub Copilot 等工具发展迅猛，它们提供高质量的图形用户界面，能够以惊人的流畅度管理上下文和复杂的多步骤操作。这些工具正在重新定义开发人员所需的高效、智能体驱动的界面。现在，我们也应该认真思考下一代人工智能驱动的智能体用户体验将如何应用于其他行业——律师、会计师、保险专业人士、产品经理和知识工作者。未来的工作可能不再围绕文档、电子表格和幻灯片展开，而是围绕专为决策、分析和协作而构建的交互式、智能体驱动的界面展开。创造。

Graphical interfaces excel in use cases where data visualization, structured interactions, and clear status updates are essential. Recent years have seen enormous growth in tools like Lovable, Cursor, Windsurf, and GitHub Copilot, which offer high-quality GUIs that manage context and complex multistep operations with remarkable fluidity. These tools are redefining what productive, agent-enabled interfaces look like for developers. It is time to think just as hard about what the next generation of AI-enabled, agentic UX will be for other professions—lawyers, accountants, insurance professionals, product managers, and knowledge workers. The future of work may not revolve around documents, spreadsheets, and slide decks, but around interactive, agent-driven interfaces purpose-built for decision making, analysis, and creation.

语音和语音接口

Speech and Voice Interfaces

言语和声音这些界面为用户提供了一种自然、免手动操作的方式与智能代理系统交互，并以语音作为主要的沟通方式。从亚马逊的 Alexa 和苹果的 Siri 等虚拟助手到客服语音机器人，这些界面在手动输入不切实际或不可能的场景中表现出色，例如驾驶、烹饪或操作机器时。它们也为视力障碍或行动不便的用户提供了便捷的选择，使智能代理系统更具包容性。

Speech and voice interfaces offer users a natural and hands-free way to interact with agent systems, leveraging spoken language as the primary mode of communication. From virtual assistants like Amazon’s Alexa and Apple’s Siri to customer service voice bots, these interfaces excel in scenarios where manual input is impractical or impossible—such as while driving, cooking, or operating machinery. They also provide an accessible option for users with visual impairments or limited mobility, making agent systems more inclusive.

从历史上看，延迟语音和语音交互界面一直面临着巨大的挑战。实时处理口语——包括语音转录、意图解读和生成相应的响应——常常会导致延迟，从而打断对话流程，使语音界面显得笨拙或生硬。然而，过去两年，这一领域取得了令人瞩目的进步。新型低延迟语音识别模型与更高效的语言处理架构相结合，显著降低了延迟。同样重要的是，语音人工智能系统的流畅性和功能也得到了提升，从而能够实现更加自然流畅的交互，并能应对对话中断、句子中的纠正以及话题的转换。

Historically, latency has been a major barrier for speech and voice interfaces. Processing spoken language in real time—including transcribing speech, interpreting intent, and generating appropriate responses—often led to delays that disrupted conversational flow and made voice interfaces feel clunky or robotic. However, the past two years have seen astonishing advances in this space. New low-latency speech recognition models, combined with more efficient language processing architectures, have dramatically reduced delays. Equally important, the fluidity and capability of voice AI systems have improved, enabling more natural-sounding interactions that can handle interruptions, mid-sentence corrections, and shifts in conversation topic.

优雅地处理中断是语音界面设计中一个尤为重要的方面。人类对话很少是线性的独白；人们常常会在句子进行到一半时打断自己，以澄清、改变方向或完善请求。高效的语音助手必须体现这种对话的灵活性，允许用户在不引起困惑的情况下中断命令，无缝地修改输入，并在无需完全重新开始的情况下从中断处继续对话。例如，用户可能会说：“帮我预订一张桌子——哦，等等，改成明天吧。”一个设计良好的助手会流畅地适应这一更正，而无需用户重新开始命令。这种能力不仅使交互感觉更加自然，还能建立信任并减少挫败感，因为用户会觉得助手能够响应他们真实的沟通模式，而不是要求他们做出僵硬的、类似电脑的输入。

Graceful handling of interruptions is a particularly important aspect of voice interface design. Human conversations are rarely linear monologues; people interrupt themselves to clarify, change direction, or refine a request mid-sentence. Effective voice agents must mirror this conversational flexibility, allowing users to interrupt commands without confusion, revise their inputs seamlessly, and resume where they left off without forcing a complete restart. For example, a user might say, “Book me a table for—oh wait, make that tomorrow instead,” and a well-designed agent will adapt fluidly to incorporate the correction without requiring the user to start the command again. This capability not only makes interactions feel more natural but also builds trust and reduces frustration, as users feel the agent is responsive to their real communication patterns rather than demanding rigid, computer-like inputs.

另一项重大飞跃是将工具的使用集成到语音代理的工作流程中。现代语音代理不再局限于解析命令并返回静态答案。相反，它们现在可以获取外部上下文信息、更新记录，并根据动态对话输入执行实时操作，例如安排预约、更改系统配置或下单。这种将自然语音交互与结构化后端操作相结合的能力，正在彻底改变语音代理的功能。

Another major leap has been the integration of tool use into voice agent workflows. Modern voice agents are no longer limited to parsing commands and returning static answers. Instead, they can now pull in external context, update records, and take real-time actions—such as scheduling appointments, changing system configurations, or placing orders—based on dynamic conversational inputs. This ability to combine natural voice interaction with structured backend operations is transforming what voice agents can achieve.

尽管语音界面技术取得了令人瞩目的进步，但值得注意的是，它仍然是一项前沿技术。诚然，语音界面已在智能音箱和简易助手等主流应用中得到广泛应用。然而，具备完全对话性、多轮对话能力、上下文感知能力以及执行操作能力的语音代理尚未在各行业得到广泛部署。许多企业才刚刚开始探索将语音界面应用于客户服务、医疗保健、物流和现场作业等领域。

Despite these impressive technological advances, it is important to note that voice interfaces remain a frontier technology. It is true that they have entered mainstream use in smart speakers and simple assistants. However, fully conversational, multiturn, context-aware voice agents with action-taking capabilities are not yet widely deployed across industries. Many enterprises are only beginning to explore voice interfaces for customer service, healthcare, logistics, and field operations.

部署语音界面时，一个关键的考虑因素是了解人类处理口语信息和书面信息的速度差异。人类通常每分钟说 150-180 个单词，而阅读速度平均为每分钟 250-300 个单词，略读速度甚至超过每分钟 500 个单词。这意味着，对于密集或复杂的信息，语音界面的处理速度必然较慢，而基于文本的界面则能实现更快的理解和更便捷的查阅。然而，在免提便利性、自然交互和即时上下文响应等优势远大于速度限制的场景下，语音界面则能发挥其优势。

A key consideration in deploying voice interfaces is understanding the speed at which humans process spoken versus written information. Humans typically speak at 150–180 words per minute, whereas reading speeds average 250–300 words per minute, with skimming speeds exceeding 500 words per minute. This means spoken interfaces are inherently slower for dense or complex information, where text-based interfaces enable faster comprehension and easier reference. However, voice excels in scenarios where hands-free convenience, natural interaction, and immediate contextual responsiveness outweigh these speed constraints.

以下示例演示了一个使用 OpenAI 实时语音 API 的极简 FastAPI 服务器。它将浏览器中的麦克风音频流传输到语音助手，并实时播放助手的语音回复。值得注意的是，它能够优雅地处理中断：如果用户在助手回复过程中开始说话，它会立即截断助手的输出，以保持对话的自然流畅。这个简洁的实现展示了构建低延迟、可感知中断的语音助手界面的核心架构：

The following example demonstrates a minimal FastAPI server using the OpenAI Realtime Voice API. It streams microphone audio from a browser to the agent and plays back the assistant’s audio responses in real time. Notably, it handles interruptions gracefully: if the user starts speaking mid-response, it immediately truncates the assistant’s output to keep the conversation natural. This compact implementation shows the core architecture for building low-latency, interruption-aware voice interfaces with agents:

import os, json, base64, asyncio, websockets
from fastapi import FastAPI, WebSocket
from dotenv import load_dotenv

load_dotenv()
OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
VOICE          = "alloy"                 # GPT-4o voice
PCM_SR         = 16000                   # sample-rate we'll use client-side
PORT           = 5050

app = FastAPI()

@app.websocket("/voice")
async def voice_bridge(ws: WebSocket) -> None:
    """
    1. Browser opens ws://host:5050/voice
    2. Browser streams base64-encoded 16-bit mono PCM chunks: {"audio": "<b64>"}
    3. We forward chunks to OpenAI Realtime (`input_audio_buffer.append`)
    4. We relay assistant audio deltas back to the browser the same way
    5. We listen for 'speech_started' events and send a truncate if 
       user interrupts
    """
    await ws.accept()

    openai_ws = await websockets.connect(
        "wss://api.openai.com/v1/realtime?" + 
            "model=gpt-4o-realtime-preview-2024-10-01" (split across two lines)
        extra_headers={
            "Authorization": f"Bearer {OPENAI_API_KEY}",
            "OpenAI-Beta" : "realtime=v1"
        },
        max_size=None, max_queue=None # unbounded for demo simplicity
    )

    # initialize the realtime session
    await openai_ws.send(json.dumps({
        "type": "session.update",
        "session": {
            "turn_detection": {"type": "server_vad"},
            "input_audio_format": f"pcm_{PCM_SR}",
            "output_audio_format": f"pcm_{PCM_SR}",
            "voice": VOICE,
            "modalities": ["audio"],
            "instructions": "You are a concise AI assistant."
        }
    }))

    last_assistant_item = None          # track current assistant response
    latest_pcm_ts       = 0             # ms timestamp from client
    pending_marks       = []

    async def from_client() -> None:
        """Relay microphone PCM chunks from browser → OpenAI."""
        nonlocal latest_pcm_ts
        async for msg in ws.iter_text():
            data = json.loads(msg)
            pcm = base64.b64decode(data["audio"])
            latest_pcm_ts += int(len(pcm) / (PCM_SR * 2) * 1000) 
            await openai_ws.send(json.dumps({
                "type": "input_audio_buffer.append",
                "audio": base64.b64encode(pcm).decode("ascii")
            }))

    async def to_client() -> None:
        """Relay assistant audio + handle interruptions."""
        nonlocal last_assistant_item, pending_marks
        async for raw in openai_ws:
            msg = json.loads(raw)

            # assistant speaks
            if msg["type"] == "response.audio.delta":
                pcm = base64.b64decode(msg["delta"])
                await ws.send_json({"audio": 
                    base64.b64encode(pcm).decode("ascii")})
                last_assistant_item = msg.get("item_id")

            # user started talking → cancel assistant speech
            started = "input_audio_buffer.speech_started"
            if msg["type"] == started and last_assistant_item:
                await openai_ws.send(json.dumps({
                    "type": "conversation.item.truncate",
                    "item_id": last_assistant_item,
                    "content_index": 0,
                    "audio_end_ms": 0   # stop immediately
                }))
                last_assistant_item = None
                pending_marks.clear()

    try:
        await asyncio.gather(from_client(), to_client())
    finally:
        await openai_ws.close()
        await ws.close()

if __name__ == "__main__":
    import uvicorn
    uvicorn.run("realtime_voice_minimal:app", host="0.0.0.0", port=PORT)

展望未来，在成本下降、延迟降低、语音识别能力提升以及与后端工具更好地协同工作等因素的推动下，未来几年高级语音界面有望得到广泛应用。在医疗保健领域，语音助手可以帮助医生在患者咨询过程中进行免提笔记记录。在客户服务领域，语音助手正在取代僵硬的人工客服。交互式语音应答 (IVR) 系统提供流畅、类人化的对话，能够实现端到端的问题解决。在工业应用中，工人无需停止工作即可控制机器、记录观察结果或查阅手册。

Looking ahead, we are likely to see significant adoption of advanced voice interfaces in the coming years, driven by falling costs, reduced latency, improved speech recognition, and better orchestration with backend tools. In healthcare, voice agents can assist doctors with hands-free note-taking during patient consultations. In customer service, they are replacing rigid interactive voice response (IVR) systems with fluid, humanlike conversations that resolve issues end to end. In industrial applications, workers can control machinery, log observations, or access manuals without stopping their tasks.

归根结底，语音界面最适用于简短的免提任务、快速查询和以行动为导向的工作流程，而不是用于密集的信息消费或需要快速浏览或并排比较的复杂决策。

Ultimately, voice interfaces are most effective for short, hands-free tasks, quick queries, and action-oriented workflows, rather than for dense information consumption or complex decision making that requires rapid skimming or side-by-side comparison.

精心设计的语音界面能够为用户与智能体交互提供无与伦比的便捷性、易用性和灵活性。随着这些技术的不断成熟，以及与后端工具和知识系统的深度集成，它们有望成为日常工作流程、个人助理和企业解决方案中不可或缺的一部分，从根本上改变用户与人工智能交互的方式。代理人。

When thoughtfully designed, speech and voice interfaces offer unparalleled convenience, accessibility, and flexibility in agent interactions. As these technologies continue to mature and integrate deeply with backend tools and knowledge systems, they are poised to become indispensable in daily workflows, personal assistants, and enterprise solutions—fundamentally transforming how users interact with AI-powered agents.

基于视频的界面

Video-Based Interfaces

基于视频人机交互界面是一种新兴的智能体交互方式，它将视觉、听觉，有时甚至是文本元素融合到一个统一的体验中。这些界面涵盖范围很广，从模拟面对面对话的视频化身到嵌入实时视频协作工具的智能体，应有尽有。随着视频在我们的数字生活中日益普及——例如通过 Zoom、Microsoft Teams 和虚拟活动空间等平台——智能体也在不断探索融入这些环境的新途径。尽管许多此类体验仍处于“恐怖谷”阶段，但其快速的改进速度表明这项技术正逐渐走向成熟，未来将有更多团队开始围绕它构建各种体验。

Video-based interfaces are an emerging modality for agent interactions, blending visual, auditory, and sometimes textual elements into a single cohesive experience. These interfaces can range from video avatars that simulate face-to-face conversations to agents embedded in real-time video collaboration tools. As video becomes more pervasive in our digital lives—through platforms like Zoom, Microsoft Teams, and virtual event spaces—agents are finding new ways to integrate into these environments. While many of these experiences are still in the uncanny valley, the rapid pace of improvement suggests that this technology is getting closer to prime time, and more teams will begin building experiences around it.

视频界面的一大核心优势在于其能够将多种感官通道——视觉线索、语音、文字叠加和动画——融合在一起，从而实现更丰富、更具表现力的交互。视频代理可以模仿人类的表情和手势，为沟通增添情感上的细微差别。例如，人工智能驱动的客服虚拟形象可以通过面部表情和手势来安抚沮丧的客户，用视觉上的同理心来补充其口头回复。

One of the core strengths of video interfaces is their ability to combine multiple sensory channels—visual cues, speech, text overlays, and animations—into a richer, more expressive interaction. Video agents can mimic humanlike expressions and gestures, adding emotional nuance to their communication. For example, an AI-powered customer service avatar might use facial expressions and hand gestures to reassure a frustrated customer, complementing its spoken responses with visual empathy.

然而，视频界面也面临着技术和设计上的挑战。高质量的视频交互需要强大的处理能力和带宽，这可能会导致延迟或像素化，从而影响用户体验。“恐怖谷效应”仍然存在风险——如果角色的面部表情、手势或口型同步稍有不自然，就会造成不适而非吸引用户。此外，隐私问题也不容忽视。对于视频代理来说，这些担忧会更加严重，因为用户可能不愿与人工智能系统共享视觉数据。

However, video interfaces come with technical and design challenges. High-quality video interactions require significant processing power and bandwidth, which can introduce lag or pixelation, undermining the user experience. The uncanny valley remains a risk—if an agent’s facial expressions, gestures, or lip-syncing feel slightly off, it can create discomfort rather than engagement. Additionally, privacy concerns are amplified with video agents, as users may feel uneasy about sharing visual data with AI systems.

展望未来，视频界面有望迎来显著增长，尤其是在渲染、实时动画和带宽优化等方面的改进能够有效解决当前瓶颈之后。在不久的将来，我们有望看到客服人员无缝融入虚拟会议、增强现实（AR）叠加层以及数字化客服化身。

Looking ahead, video interfaces are poised for significant growth, especially as improvements in rendering, real-time animation, and bandwidth optimization address current limitations. In the near future, expect to see agents embedded seamlessly into virtual meetings, augmented reality (AR) overlays, and digital customer service avatars.

精心设计的视频界面能够为智能体交互增添引人入胜、人性化的维度，从而提升清晰度、情感连接和整体效率。随着技术的进步，基于视频的智能体将在远程医疗、教育、远程协作和互动娱乐等行业中扮演越来越重要的角色，重塑人类与智能体在沉浸式数字环境中的沟通方式。空格。

When thoughtfully executed, video interfaces offer an engaging, humanlike dimension to agent interactions, enhancing clarity, emotional connection, and overall effectiveness. As technology advances, video-based agents are set to play a larger role in industries such as telehealth, education, remote collaboration, and interactive entertainment, reshaping how humans and agents communicate in immersive digital spaces.

融合多种模式，打造无缝体验

Combining Modalities for Seamless Experiences

虽然每个交互方式——文本、图形界面、语音和视频——各有其优势和局限性，而最引人入胜的智能体体验通常会将多种交互方式融合到一个连贯的用户体验流程中。用户不会考虑交互方式的界限；他们只想尽可能轻松自然地达成目标。能够在不同交互方式之间无缝切换，并始终保持状态和上下文，是优秀智能体系统设计的标志。

While each interaction modality—text, graphical interfaces, voice, and video—has its own strengths and limitations, the most compelling agentic experiences often combine multiple modalities into a single, cohesive user journey. Users don’t think in terms of modality boundaries; they simply want to achieve their goals as effortlessly and naturally as possible. The ability to move seamlessly across modalities—maintaining state and context throughout—is a hallmark of great agent system design.

例如，用户可能在开车时通过语音与客服人员互动，在前往会议室的途中通过手机短信继续对话，之后在笔记本电脑上查看汇总结果的图形仪表盘。在另一种情况下，语音助手可能会先朗读一份分析报告的摘要，然后通过电子邮件发送一份包含图表的详细文本版本，供用户日后参考。这种模式间的流畅切换保留了用户的上下文，尊重了情境限制，并在每个时刻提供恰当的交互方式。

For example, a user might begin interacting with an agent via voice while driving, continue the conversation on their phone through text while walking into a meeting, and later review a graphical dashboard summarizing results on their laptop. In another scenario, a voice assistant might read out a summary of an analytics report before emailing a detailed, text-based version with accompanying charts for later reference. This fluid transition between modalities preserves user context, respects situational constraints, and delivers the right interaction style at each moment.

为了实现模态间的流畅切换，设计时需要精心管理状态并保持上下文的持久性，以确保信息、任务进度和用户偏好在切换过程中不会丢失。此外，智能体还必须根据不同的模态调整其沟通方式——例如，提供简洁的语音摘要，同时提供更详细的文本输出以供审阅。

Designing for modality fluidity requires careful state management and context persistence so that information, task progress, and user preferences are never lost in transition. Agents must also adapt their communication style to suit each modality—for example, delivering concise spoken summaries while providing more detailed textual outputs for review.

对于人机交互领域而言，这是一个激动人心的时代。基础模型、多模态架构和代理编排方面的最新进展，正在开启与智能系统交互的全新方式。如今，构建能够在单一统一的工作流程中，跨文本、语音、图像和视频与用户互动的代理，在技术上已首次成为可能。

This is an exciting time for the field of human-computer interaction. Recent advances in foundation models, multimodal architectures, and agent orchestration are unlocking entirely new ways of interacting with intelligent systems. For the first time, it is technically feasible to build agents that engage users across text, voice, images, and video in a single, unified workflow.

然而，尽管技术前沿飞速发展，但至关重要的是要记住，用户体验和产品的核心原则始终不变。打造成功的客服体验并非为了炫耀最新的模态集成或生成式用户界面功能，而是为了深入了解用户，设身处地地为他们着想，并创造直观、值得信赖且令人愉悦的体验，从而解决他们生活中的实际问题。

However, while the technology frontier is expanding rapidly, it is critical to remember that core UX and product principles remain unchanged. Building successful agent experiences isn’t about showcasing the latest modality integrations or generative UI capabilities for their own sake. It is about understanding users deeply, meeting them where they are, and creating intuitive, trustworthy, and delightful experiences that solve real problems in their lives.

最好的产品并非仅仅展现技术上的精湛，而是以优雅而巧妙的方式运用技术来增强人类的能力。在我们不断拓展模态设计边界的同时，让我们始终坚守卓越产品设计的永恒目标：创造人们乐于使用、简化生活、赋能于人的工具，从而实现他们的目标。最重要的事。

The best products are not those that merely demonstrate technological sophistication, but those that use technology to amplify human capability in elegant and unobtrusive ways. As we continue to push the boundaries of modality design, let us stay grounded in the timeless goal of great product design: creating tools that people love to use, that make their lives easier, and that empower them to achieve what matters most.

自主度滑块

The Autonomy Slider

一个至关重要但又常常被忽视的维度用户体验设计指的是赋予智能体的自主程度。正如Andrej Karpathy 所描述的，有效的智能体系统应该允许用户平滑地调整智能体的自主程度——从完全手动控制到部分自动化，再到完全自主运行。这种概念通常被称为自主度滑块，它使用户能够随时选择保留多少控制权以及委托多少控制权。图 3-4展示了一个简单的自主度滑块界面示例，用户可以根据任务、信任程度和上下文将智能体设置为“手动”、“询问”或“智能体”模式。

A critical yet often overlooked dimension in UX design is the level of autonomy granted to agents. As Andrej Karpathy described, effective agentic systems should allow users to smoothly adjust an agent’s autonomy—from fully manual control to partial automation to fully autonomous operation. This concept, often called an autonomy slider, empowers users to choose how much control they wish to retain versus delegate at any given time. Figure 3-4 illustrates a simple example of an autonomy slider interface, enabling users to set the agent to “Manual,” “Ask,” or “Agent” mode depending on their task, trust, and context.

图 3-4。自主度滑块使用户能够调整代理的独立程度，从完全手动控制到辅助“询问”模式，再到完全自主的代理执行。这种灵活性通过使系统行为与用户偏好、任务复杂性和上下文保持一致，从而建立用户信任。

不同的用户、任务和场景对智能体的自主程度要求也不同。在某些情况下，用户倾向于完全手动控制以确保精确性；而在另一些情况下，他们可能希望将例行或复杂的任务完全交给智能体处理。关键在于，这些偏好并非一成不变；它们会随着用户信任度、任务熟悉程度、风险和工作量而变化。例如：

Different users, tasks, and contexts demand different degrees of agent autonomy. In some situations, users prefer full manual control to ensure precision, while in others, they may want to offload routine or complex tasks entirely to the agent. Critically, these preferences are not static; they evolve with user trust, task familiarity, stakes, and workload. For example:

手动的

Manual

开发商所有代码均由程序自动编写，无需任何辅助工具。该集成开发环境 (IDE) 仅作为编辑器使用，提供语法高亮和代码检查功能，但不提供任何人工智能驱动的建议。

The developer writes all code themselves without agent assistance. The IDE acts purely as an editor with syntax highlighting and linting but no AI-driven suggestions.

（协助）

Ask (assisted)

代理人主动它会提供代码补全、重构或文档片段的建议，但每个建议都需要开发者审核并接受后才能应用。这种模式既能加快开发速度，又能确保开发者完全掌控开发过程。

The agent proactively suggests code completions, refactors, or documentation snippets, but the developer reviews and accepts each suggestion before it is applied. This mode speeds up development while keeping the human fully in control.

代理人

Agent

代理人它能够自主执行某些任务，例如应用标准重构、修复代码检查错误或根据项目规范生成样板代码文件，而无需单独审批。开发人员会收到变更通知，但无需批准每一项操作。

The agent autonomously performs certain tasks, such as applying standard refactors, fixing linter errors, or generating boilerplate code files based on project conventions without requiring individual approvals. The developer is notified of changes but does not need to approve each action.

这三种模式展示了自主度滑块如何帮助开发者在单一界面中平衡控制和效率。同样的原理也适用于软件开发以外的领域。例如，在……客户支持平台：

These three modes demonstrate how an autonomy slider empowers developers to balance control and efficiency within a single interface. The same principle applies beyond software development. For example, in a customer support platform:

手动的

Manual

所有客户咨询均由人工客服处理。人工智能要么处于非激活状态，要么仅用于后端分析，不参与一线互动。

Human agents handle all incoming customer queries themselves. The AI is inactive or used only for backend analytics, not frontline interactions.

（协助）

Ask (assisted)

代理程序会生成针对客户消息的建议回复，其中包含推荐的回复内容、政策参考或故障排除步骤。人工客服会在发送前审核、编辑（如有必要）并批准回复。这既加快了响应速度，又保留了人工判断的准确性。

The agent drafts suggested replies to customer messages, surfacing recommended responses, policy references, or troubleshooting steps. The human agent reviews, edits if necessary, and approves the reply before sending. This accelerates response time while maintaining human judgment.

代理人

Agent

该智能体可自主处理常规查询，例如密码重置、订单跟踪或常见问题解答，无需人工干预，仅将复杂或敏感问题上报给人工客服。用户会收到智能体操作的通知，但无需对每条消息进行确认。

The agent autonomously handles routine queries—such as password resets, order tracking, or FAQs—without human intervention, escalating only complex or sensitive issues to human agents. Users are notified of agent actions but do not need to approve each message for standard interactions.

这三种模式共存于同一客户支持系统中，使团队能够根据查询的复杂性、客户画像以及组织对人工智能的信任度来调整自主程度。这种自主程度调节模式可以扩展到任何工作流程能够灵活切换手动执行、人工智能辅助和完全自动化代理的领域。这种自主程度的调节必须有意识地融入到代理体验中。否则，代理可能会感到力不从心（如果需要过多的手动输入）或过于专断（在敏感情况下未经用户同意就采取行动）。为了有效地集成自主程度调节功能，请考虑以下因素：以下是设计原则：

These three modes coexist within the same customer support system, empowering teams to adjust autonomy based on query complexity, customer profile, and organizational trust in AI. This same autonomy slider pattern can extend to any field where workflows benefit from fluidly shifting between manual execution, AI assistance, and full agentic automation. This spectrum of autonomy must be consciously designed into agent experiences. Without it, agents risk feeling either underpowered (if they require too much manual input) or overbearing (if they act without user consent in sensitive contexts). To integrate an autonomy slider effectively, consider the following design principles:

明确展现自主程度

Expose degrees of autonomy clearly

用户应了解代理独立性的不同级别，从手动、辅助到自主。请使用直观的语言标记这些模式，例如“手动”、“辅助”和“自动”，并解释其含义。

Users should understand the available levels of agent independence, from manual to assisted to autonomous. Label these modes in intuitive language, such as “Manual,” “Assist,” and “Auto,” and explain their implications.

实现无缝过渡

Enable seamless transitions

用户必须能够根据自身信心、工作环境或工作量的变化，轻松切换不同的自主权限级别。例如，界面中的切换开关或滑块应该能够让用户快速从审核模式切换到自动批准模式。

Users must be able to shift between autonomy levels effortlessly as their confidence, context, or workload changes. For instance, a toggle or slider in the interface should offer a quick transition from review mode to auto-approve mode.

在各个层面提供可预测和透明的行为。

Provide predictable and transparent behavior at each level

每个自主级别都应具有明确定义的行为。例如，在部分自动化中，代理可以生成输出，但需要用户明确批准后才能执行。在完全自主中，它仍然应该提供状态更新和干预选项。

Each autonomy level should have well-defined behaviors. In partial automation, for example, the agent may draft an output but require explicit user approval before execution. In full autonomy, it should still provide status updates and options to intervene.

沟通每个级别的风险和收益

Communicate the risks and benefits of each level

用户应清楚提高代理自主性所带来的收益和风险。对于关键任务，建议在启用完全自主性之前，先征得用户的明确确认。

Users should be aware of what they gain or risk by increasing agent autonomy. For critical tasks, it may be advisable to require an explicit user confirmation before enabling full autonomy.

根据用户信任度和能力调整自主性

Adapt autonomy based on user trust and competence

随着用户信任度的提升和智能体可靠性的提高，智能系统可以逐步建议更高的自主级别。例如，在手动模式下成功使用 10 次后，系统可能会建议尝试辅助模式以节省时间。

Intelligent systems can gradually suggest higher autonomy levels as users gain trust and as the agent demonstrates reliability. For example, after 10 successful uses in manual mode, the system might suggest trying assist mode to save time.

重要的是，自主度滑块不仅仅是一项功能，更是一种建立信任的机制。通过让用户控制智能体的自主程度，系统能够体现对用户专业知识和自主性的尊重。它避免了“一刀切”式自主度的常见陷阱，这种模式要么让用户不堪重负，要么限制了用户的潜力。始终要问自己：我的用户能否轻松地在手动、辅助和完全自主模式之间切换？这个问题的答案将决定你的智能体是被用户视为可靠的合作伙伴，还是被边缘化。作为一种不受信任的工具。

Importantly, the autonomy slider is not merely a feature—it is a trust-building mechanism. By giving users control over how much autonomy an agent exercises, systems communicate respect for user expertise and agency. It avoids the common pitfall of “one-size-fits-all” autonomy that either overwhelms or underutilizes user potential. Always ask: how easily can my users move between manual, assisted, and fully autonomous modes? The answer to this question will shape whether your agent is adopted as a reliable partner or sidelined as an untrusted tool.

同步体验的设计原则

Design Principles for Synchronous Experiences

同步代理用户体验的成功离不开即时性、清晰度和响应速度。用户期望客服人员能够快速响应，保持对话流畅性和上下文连贯性，避免明显的延迟。无论是在线聊天、语音通话还是实时数据仪表盘，同步交互都需要低延迟和上下文感知能力，以避免令人沮丧的停顿或重复提问。

Synchronous agent experiences thrive on immediacy, clarity, and responsiveness. Users expect agents in these settings to respond quickly and maintain conversation flow and context without noticeable delays. Whether in a live chat, voice call, or real-time data dashboard, synchronous interactions demand low latency and context awareness to avoid frustrating pauses or repetitive questions.

在同步环境中，智能体应优先考虑回复的清晰性和简洁性。冗长的解释或过于复杂的输出会破坏实时交互的节奏。此外，轮流发言机制——即何时回应、何时等待以及何时升级对话——对于维持自然高效的对话流程至关重要。诸如输入指示器或进度条之类的视觉提示可以让用户确信智能体正在积极处理他们的输入。

Agents in synchronous environments should prioritize clarity and brevity in their responses. Long-winded explanations or overly complex outputs can break the rhythm of real-time interactions. Additionally, turn-taking mechanics—knowing when to respond, when to wait, and when to escalate—are critical for maintaining a natural and productive conversation flow. Visual cues, like typing indicators or progress spinners, can reassure users that the agent is actively processing their input.

在同步设计中，错误处理同样重要。智能体必须能够优雅地从误解或故障中恢复，避免中断交互。当出现不确定性时，同步智能体应该提出澄清问题或温和地引导用户，而不是做出冒险的假设。这些原则能够创造流畅、直观的体验，保持用户参与度，并在不产生不必要干扰的情况下维护上下文。摩擦。

Error handling is equally important in synchronous designs. Agents must gracefully recover from misunderstandings or failures without derailing the interaction. When uncertainty arises, synchronous agents should ask clarifying questions or gently redirect users rather than making risky assumptions. These principles create a smooth, intuitive experience that keeps users engaged and maintains context without unnecessary friction.

异步体验的设计原则

Design Principles for Asynchronous Experiences

异步智能体体验优先考虑灵活性、持久性和清晰度。这些交互通常发生在无需立即响应的场景中，例如智能体正在处理长时间运行的任务、准备详细报告或监控后台事件时。

Asynchronous agent experiences prioritize flexibility, persistence, and clarity over time. These interactions often occur in contexts where immediate responses aren’t necessary, such as when agents are processing long-running tasks, preparing detailed reports, or monitoring background events.

高效的异步代理必须擅长清晰地传达任务状态和结果。用户应该始终了解代理正在做什么、任务处于哪个阶段以及何时可以收到更新。通知、摘要和结构清晰的报告是保持透明度的关键工具。例如，生成分析报告的代理可以在处理开始时通知用户，提供预计完成时间，并在完成后提供简洁明了、可操作的摘要。

Effective asynchronous agents must excel at clear communication of task status and outcomes. Users should always understand what the agent is doing, what stage a task is in, and when they can expect an update. Notifications, summaries, and well-structured reports become key tools for maintaining transparency. For example, an agent generating an analytical report might notify the user when processing begins, provide an estimated completion time, and deliver a concise, actionable summary when finished.

上下文管理是异步和同步代理的另一个关键设计原则。由于用户与代理之间的交互可能存在较长的延迟，代理必须无缝地保留和引用历史上下文。用户在返回正在进行的任务时，不应需要重复信息或重新执行之前的步骤。我们将在第六章“记忆”部分更详细地讨论这一点。

Context management is another critical design principle for both asynchronous and synchronous agents. Because there may be long delays between user-agent interactions, agents must retain and reference historical context seamlessly. Users shouldn’t need to repeat information or retrace previous steps when returning to an ongoing task. We’ll cover this in more detail in Chapter 6 on memory.

最后，异步客服人员必须有效管理用户预期。清晰的时间安排、进度指示器和后续通知可以避免因不确定性或缺乏客服人员工作透明度而导致的沮丧情绪。

Lastly, asynchronous agents must manage user expectations effectively. Clear timelines, progress indicators, and follow-up notifications prevent frustration caused by uncertainty or lack of visibility into an agent’s work.

在主动和侵入式代理行为之间找到平衡点

Finding the Balance Between Proactive and Intrusive Agent Behavior

其中最智能体设计中一些微妙之处——无论是同步还是异步——在于如何确定智能体何时以及如何主动与用户互动。主动互动非常有益，例如智能体提醒用户注意紧急问题、提出优化建议或提供及时提醒。然而，不恰当的通知或过于侵入性的行为会让用户感到沮丧，扰乱他们的工作流程，甚至导致他们完全放弃使用。

One of the most delicate aspects of agent design—whether synchronous or asynchronous—is determining when and how agents should proactively engage users. Proactivity can be immensely helpful, such as when an agent alerts a user to an urgent issue, suggests an optimization, or provides a timely reminder. However, poorly timed notifications or intrusive behaviors can frustrate users, disrupt their workflow, or even cause them to disengage entirely.

平衡主动性和用户控制的关键在于情境感知。智能体应了解用户当前的关注点、紧急程度和沟通偏好。例如，在重要视频会议期间发送主动提醒可能弊大于利，而通过电子邮件发送任务完成通知则可能非常合适。

The key to balancing proactivity lies in context awareness and user control. Agents should understand the user’s current focus, level of urgency, and communication preferences. For instance, a proactive alert during a high-stakes video meeting might be more disruptive than helpful, while a notification about a completed task delivered via email might be perfectly appropriate.

客服人员在主动联系用户时，应优先考虑相关性。通知和建议必须真正有价值——解决问题或提供见解，而不是制造噪音。此外，用户应能控制通知频率、渠道和升级阈值，从而根据自身需求定制客服人员的行为。

Agents should also prioritize relevance when proactively reaching out. Notifications and suggestions must add genuine value—solving problems or providing insights rather than adding noise. Additionally, users should have control over notification frequency, channels, and escalation thresholds, enabling them to customize agent behavior to suit their needs.

实现这种平衡不仅仅关乎技术能力，更关乎对用户工作流程和心理状态的同理心。精心设计的智能代理能够将主动互动无缝融入交互过程中，在不显得突兀的情况下提升效率、减少摩擦。霸道。

Striking this balance isn’t just about technical capability—it’s about empathy for the user’s workflow and mental state. Well-designed agents seamlessly weave proactive engagement into their interactions, enhancing productivity and reducing friction without becoming overbearing.

跨交互保持状态

Maintaining State Across Interactions

国家管理上下文连续性是智能体系统中实现上下文连续性的基础。为了确保交互流畅，智能体必须准确跟踪已发生的情况、用户的预期目标以及下一步的逻辑操作。这在多轮对话、任务交接以及包含中间状态的工作流中尤为重要，因为上下文丢失会导致用户感到沮丧、效率低下，甚至放弃任务。

State management is the foundation of context continuity in agent systems. For an interaction to feel seamless, an agent must accurately track what has happened so far, what the user intends to achieve, and what the next logical step is. This is particularly important in multiturn conversations, task handoffs, and workflows with intermediate states, where losing context can result in frustration, inefficiency, and abandonment of tasks.

有效的状态管理取决于系统如何识别和跟踪用户或会话。对于已登录用户，状态可以直接与其用户帐户关联，从而实现跨设备和会话的记忆持久性。对于匿名交互，维护上下文通常需要会话标识符（例如 cookie 或令牌）来跟踪客户端和服务器之间的通信。

Effective state management depends on how the system identifies and tracks users or sessions. For logged-in users, state can be tied directly to their user accounts, enabling memory persistence across devices and sessions. For anonymous interactions, maintaining context typically requires a session identifier—such as a cookie or token—to track the conversation between the client and server.

随着代理系统规模扩展到数千甚至数百万用户，会话状态不应仅驻留在记忆中。将状态持久化到数据库或分布式缓存中，可确保服务器重启后会话的连续性，实现负载均衡，并支持多设备体验。以下两种选择值得考虑：用户型记忆（持久性、个性化）和基于会话的记忆（临时的、会话范围的）取决于您的应用程序的隐私设置。需求、用户期望和运营架构。无论采用何种实现方式，强大的识别和存储策略都是大规模提供无缝、情境感知型代理体验的基础。

As agent systems scale to thousands or millions of users, session state should not reside only in memory. Persisting state in a database or distributed cache ensures continuity across server restarts, enables load balancing, and supports multidevice experiences. The choice between user-based memory (persistent, personalized) and session-based memory (ephemeral, session-scoped) depends on your application’s privacy requirements, user expectations, and operational architecture. Regardless of implementation, robust identification and storage strategies are fundamental to delivering seamless, context-aware agent experiences at scale.

智能体可以通过短期会话记忆来维持状态，将正在进行的交互细节（例如用户最近的命令或未完成的任务）临时存储，直到会话结束。在更高级的系统中，持久状态管理使智能体能够在多个会话中恢复任务，以便用户即使在数小时或数天后也能从上次中断的地方继续操作。

Agents can maintain state through short-term session memory, where details of the ongoing interaction—such as a user’s recent commands or incomplete tasks—are temporarily stored until the session ends. In more advanced systems, persistent state management enables agents to resume tasks across multiple sessions so that users can pick up where they left off, even after hours or days have passed.

有效的状态保留需要清晰的会话边界、数据验证和回退机制。如果代理忘记了上下文，它应该通过询问澄清问题来优雅地恢复，而不是做出错误的假设。此外，状态数据必须得到安全负责的管理，尤其是在涉及敏感信息或个人身份信息时。

Effective state retention requires clear session boundaries, data validation, and fallback mechanisms. If an agent forgets context, it should gracefully recover by asking clarifying questions rather than making incorrect assumptions. Additionally, state data must be managed securely and responsibly, especially when it involves sensitive or personally identifiable information.

有效的状态管理能够帮助代理引导用户完成复杂任务，避免不必要的重复操作，降低认知负荷，并营造持续协作的氛围。无论代理是帮助用户预订住宿、解决技术问题，还是管理多步骤审批流程，有效的状态管理都能确保交互的顺利进行。保持流畅、逻辑清晰和高效。

When done well, maintaining state enables agents to guide users through complex tasks without unnecessary repetition, reduce cognitive load, and create a sense of ongoing collaboration. Whether an agent is helping a user book travel accommodations, troubleshoot a technical issue, or manage a multistep approval process, effective state management ensures interactions remain smooth, logical, and productive.

个性化和适应性

Personalization and Adaptability

个性化个性化不仅限于记住上下文——它还利用过去的互动和偏好来定制智能体的行为、响应和推荐，使其更符合用户的个性化需求。一个适应性强的智能体不仅维护自身状态，还能从之前的互动中学习，从而提供越来越精准、越来越相关的结果。个性化可以采取多种形式：

Personalization goes beyond merely remembering context—it involves using past interactions and preferences to tailor the agent’s behavior, responses, and recommendations to individual users. An adaptable agent doesn’t just maintain state; it learns from previous exchanges to deliver increasingly refined and relevant outcomes. Personalization can take multiple forms:

偏好保留

Preference retention

记住用户设置，例如通知偏好或常用选项

Remembering user settings, such as notification preferences or commonly chosen options

行为适应

Behavioral adaptation

根据观察到的用户模式调整响应方式或交互流程

Adjusting response style or interaction flow based on observed user patterns

主动协助

Proactive assistance

预测用户需求并根据其过往行为提供建议

Anticipating user needs and offering suggestions based on past behavior

例如，协助项目管理的客服人员可以识别用户偏好的任务跟踪方式，并据此调整通知或摘要。同样，客服人员也可以根据用户偏好简洁的回答还是详细的解释来调整语气和措辞。

For example, an agent assisting with project management might recognize a user’s preferred task-tracking style and adapt its notifications or summaries accordingly. Similarly, a customer service agent might adjust its tone and verbosity based on whether the user prefers concise answers or detailed explanations.

然而，个性化也面临着挑战。隐私必须妥善处理用户的担忧，并以透明的方式沟通存储哪些数据以及如何使用这些数据。此外，代理必须权衡如何既能提供有益的适应性，又不至于过于坚持——用户应该始终可以选择重置或覆盖个性化设置。

However, personalization comes with challenges. Privacy concerns must be carefully managed, with transparent communication about what data is being stored and how it is being used. Additionally, agents must strike a balance between being helpfully adaptive and overly persistent—users should always have the option to reset or override personalized settings.

最佳的个性化体验是悄无声息却又影响深远的，智能体在不引起用户注意的情况下，巧妙地提升用户体验。巅峰的个性化体验能让用户感受到理解和支持，仿佛智能体是一位体贴的合作伙伴，而非机械的工具。

The best personalization feels invisible yet impactful, where the agent subtly improves the user experience without drawing attention to its adjustments. At its peak, personalization creates an experience where users feel understood and supported, as if the agent is a thoughtful collaborator rather than a mechanical tool.

沟通信心与不确定性

Communicating Confidence and Uncertainty

智能体经常在概率环境中运行，其输出基于统计模型而非确定性规则。因此，并非每个响应或操作都具有相同的置信度。有效沟通不确定性对于建立用户信任和帮助用户做出明智决策至关重要。

Agents often operate in probabilistic environments, generating outputs based on statistical models rather than deterministic rules. As a result, not every response or action carries the same degree of confidence. Communicating uncertainty effectively is essential for building user trust and helping users make informed decisions.

置信水平可以用多种方式表示：

Confidence levels can be expressed in several ways:

明确声明

Explicit statements

“我有90%的把握这是正确答案。”

“I’m 90% certain this is the correct answer.”

视觉线索

Visual cues

图形界面中的图标、颜色编码警报或置信度指示器。

Icons, color-coded alerts, or confidence meters in graphical interfaces.

行为调整

Behavioral adjustments

信心不足时，提出建议而非给出明确建议。

Offering suggestions rather than firm recommendations when confidence is low.

在不确定性较高的情况下，客服人员必须避免表现得过于自信——如果客服人员自信地给出错误或误导性的回答，用户很快就会失去信任。同样，在低风险的互动中过度谨慎也会让客服人员显得犹豫不决或不可靠。

Agents must avoid appearing overly confident when uncertainty is high—users are quick to lose trust if an agent confidently delivers an incorrect or misleading response. Similarly, excessive hedging in low-stakes interactions can make an agent appear hesitant or unreliable.

传达信心和不确定性不仅仅是分享概率；更重要的是，要根据用户的预期和互动的重要性来构建回应方式。在关键情况下，透明度至关重要，不容妥协；而在风险较低的情境下，信心的表达可以更加轻松随意。

Communicating confidence and uncertainty isn’t just about sharing probabilities; it’s about framing responses in a way that aligns with user expectations and the stakes of the interaction. In critical contexts, transparency is nonnegotiable, while in low-stakes settings, confidence can be presented more casually.

向用户征求指导和意见

Asking for Guidance and Input from Users

没有智能体，没有无论技术多么先进，智能体都能完美解读含糊不清、模棱两可或相互矛盾的用户输入。智能体不应做出冒险的假设，而应知道何时提出澄清问题或寻求用户指导。这种能力可以将潜在的错误转化为协作的机会。

No agent, no matter how advanced, can perfectly interpret ambiguous, vague, or conflicting user inputs. Instead of making risky assumptions, agents must know when to ask clarifying questions or seek user guidance. This ability transforms potential errors into opportunities for collaboration.

高效的客服人员会在遇到模糊不清的情况时，提出有针对性且有帮助的问题。例如，如果用户说“帮我订一张去芝加哥的机票”，客服人员可能会问“您想要单程票还是往返票？您有偏好的出行日期吗？” 客服人员不会给出千篇一律的答案或做出错误的假设，而是会利用这个机会来加深对用户需求的理解。

Effective agents are designed to ask focused, helpful questions when they encounter ambiguity. For example, if a user says “Book me a ticket to Chicago,” the agent might respond with “Would you like a one-way or round-trip ticket, and do you have preferred travel dates?” Instead of defaulting to a generic response or making incorrect assumptions, the agent uses the opportunity to refine its understanding.

客服人员寻求帮助的方式也很重要。问题应该清晰、礼貌且符合语境，避免使用机械式或重复的措辞。如果用户在对话的前面部分已经回答过问题，客服人员应该参考之前的上下文，而不是从头开始。

The way agents ask for guidance also matters. Questions should be clear, polite, and context-aware, avoiding robotic or repetitive phrasing. If the user has already answered part of the question earlier in the conversation, the agent should reference that context rather than starting from scratch.

此外，客服人员应该坦诚地说明他们要求用户澄清的原因。例如，简单的解释，比如“我需要更多信息才能准确地处理您的问题”，就能帮助用户理解提问背后的逻辑。

Additionally, agents should be transparent about why they’re asking for clarification. A simple explanation, like “I need a bit more information to proceed accurately,” helps users understand the rationale behind the question.

最后，客服人员应避免一次性提出太多问题——这会让用户感到不知所措，并使互动感觉像是在接受审问。相反，他们应该按照逻辑顺序提问，首先解决最关键的疑问。

Finally, agents should avoid asking too many questions at once—this can overwhelm users and make the interaction feel like an interrogation. Instead, they should sequence questions logically, addressing the most critical ambiguities first.

当代理人自信地寻求指导和意见时，他们会将不确定性转化为富有成效的合作，使用户能够引导代理人取得成功的结果，同时保持伙伴关系和共同控制的感觉。

When agents confidently ask for guidance and input, they transform uncertainty into productive collaboration, empowering users to guide the agent toward successful outcomes while maintaining a sense of partnership and shared control.

优雅地失败

Failing Gracefully

失败是不可避免的。在智能体系统中，无论是由于数据不完整、用户输入含糊不清、技术限制还是意外的极端情况，智能体都会遇到无法满足请求或完成任务的情况。然而，智能体如何处理失败与如何处理成功同样重要。一个设计良好的智能体不仅能够处理失败，还能优雅地处理失败，最大限度地减少用户的挫败感，维护用户的信任，并提供清晰的后续步骤。

Failure is inevitable in agentic systems. Whether due to incomplete data, ambiguous user input, technical limitations, or unexpected edge cases, agents will encounter scenarios where they cannot fulfill a request or complete a task. However, how an agent handles failure is just as important as how it handles success. A well-designed agent doesn’t just fail—it fails gracefully, minimizing user frustration, preserving trust, and providing a clear path forward.

优雅地处理失败的核心在于坦诚地承认问题，提供有用的解释，并提出可行的后续步骤。例如，如果客服人员找不到某个问题的答案，它可以回复“我找不到您要查找的信息；您是否希望我将此问题转交给人工客服？”，而不是给出错误或毫无意义的回答。

At its core, graceful failure involves acknowledging the issue transparently, offering a helpful explanation, and suggesting actionable next steps. For instance, if an agent cannot find an answer to a query, it might respond with “I couldn’t find the information you’re looking for; would you like me to escalate this to a human representative?” instead of producing an incorrect or nonsensical response.

代理程序的设计还应考虑常见的故障点，并预定义备用机制。例如，如果语音助手难以理解用户重复的输入，它可能会切换到文本选项或提供清晰的解释，例如：“我不太明白您的请求。请您尝试重新表述或输入您的问题好吗？”

Agents should also be designed to anticipate common points of failure and have predefined fallback mechanisms in place. For example, if a voice-based agent struggles to understand repeated user inputs, it might switch to a text-based option or provide a clear explanation, such as: “I’m having trouble understanding your request. Could you please try rephrasing it or typing your question instead?”

在多步骤任务中，当代理程序遇到故障时，状态保持同样重要。代理程序不应要求用户从头开始，而应保留进度，并在问题解决后允许用户从上次中断的地方继续操作。这可以避免不必要的重复操作和挫败感。

In multistep tasks, state preservation is equally important when an agent encounters failure. Instead of requiring the user to restart from scratch, the agent should retain progress and allow the user to pick up where they left off once the issue is resolved. This prevents unnecessary repetition and frustration.

优雅地处理失败的另一个关键方面是使用充满歉意和同理心的语言。当出现问题时，客服人员应该以人性化且体贴的方式承认错误，避免使用冷冰冰或过于​​技术化的错误信息。例如：“很抱歉，处理您的请求时出现错误。请让我再试一次，或者帮您联系可以提供帮助的人。”

Another critical aspect of graceful failure is apologetic and empathetic language. When something goes wrong, the agent should acknowledge the failure in a way that feels human and considerate, avoiding cold or overly technical error messages. For example: “I’m sorry; something went wrong while processing your request. Let me try again or connect you with someone who can help.”

此外，客服人员应提供清晰的解决问题路径。无论是提供故障排除步骤、转接人工客服，还是引导用户使用其他资源，当客服人员遇到问题时，用户都应该始终了解有哪些可行的选项。

Additionally, agents should provide clear paths to resolution. Whether it’s offering troubleshooting steps, escalating to a human operator, or directing the user to an alternative resource, users should always know what options are available to them when the agent encounters a roadblock.

最后，智能体必须尽可能从失败中吸取教训。记录故障点、分析重复出现的问题，并将这些见解反馈到开发过程中，有助于降低未来类似故障的发生频率。基于故障模式不断迭代改进的智能体，随着时间的推移，将变得越来越具有弹性和可靠性。

Lastly, agents must learn from their failures whenever possible. Logging failure points, analyzing recurring issues, and feeding these insights back into the development process can help reduce the frequency of similar failures in the future. Agents that improve iteratively based on their failure patterns will become increasingly resilient and reliable over time.

总而言之，优雅地失败意味着即使事情没有按计划进行，也要维护用户信任并最大限度地减少用户的挫败感。通过保持透明、同理心和行动导向，客服人员可以将失败转化为加强与用户关系的机会，即使在关键时刻也能展现可靠性。不完美。

In summary, failing gracefully is about maintaining user trust and minimizing frustration even when things don’t go as planned. By being transparent, empathetic, and action-oriented, agents can turn failures into opportunities to strengthen their relationship with users, demonstrating reliability even in moments of imperfection.

本地工具

Local Tools

这些这些工具设计用于本地运行。它们通常基于预定义的规则和逻辑，并针对特定任务进行定制。这些本地工具易于构建和修改，并与代理程序协同部署。它们尤其能够弥补传统编程技术在语言模型方面的不足，例如算术运算、时区转换、日历操作或地图交互等。这些本地工具具有精确性、可预测性和简洁性。由于逻辑是明确定义的，因此本地工具往往具有可预测性和可靠性。

These tools are designed to run locally. They are often based on predefined rules and logic, tailored to specific tasks. These local tools can be easily built and modified, and are co-deployed with the agent. They can especially augment weaknesses in language models that traditional programming techniques perform better at, such as arithmetic, time-zone conversions, calendar operations, or interactions with maps. These local tools offer precision, predictability, and simplicity. As the logic is explicitly defined, local tools tend to be predictable and reliable.

元数据——即工具的名称、描述和模式——与工具的逻辑同等重要。模型它会利用这些元数据来决定调用哪个工具。因此，以下内容至关重要：

The metadata—the tool’s name, description, and schema—is just as critical as its logic. The model uses that metadata to decide which tool to invoke. Therefore, the following is important:

• 选择精确且范围明确的名称。如果名称过于笼统，LLM可能会在不需要的时候调用它。

• Choose precise, narrowly scoped names. If your name is too general, the LLM may call it when it’s not needed.

• 撰写清晰、独特的描述。在多个工具中使用过于宽泛或重叠的描述会导致混乱和性能下降。

• Write clear, distinctive descriptions. Overly broad or overlapping descriptions across multiple tools guarantee confusion and poor performance.

• 定义严格的输入/输出模式。明确的模式有助于基础模型准确理解何时以及如何使用该工具，从而减少误操作。

• Define strict input/output schemas. Explicit schemas help the foundation model understand exactly when and how to use the tool, reducing misfires.

尽管有这些优点，本地工具也存在一些问题。主要缺点：

Despite these benefits, local tools have some important drawbacks:

可扩展性

Scalability

设计，构建和部署本地工具可能既繁琐又耗时，而且充满挑战，本地工具也难以在不同用例之间共享。虽然可以将工具作为库公开并在多个代理用例之间共享，但这在实践中以及大规模部署时都可能面临挑战。

Designing, building, and deploying local tools can be cumbersome, time-consuming, and challenging, and local tools are harder to share across use cases. While tools can be exposed as libraries and shared across multiple agent use cases, this can be challenging in practice and at scale.

复制

Duplication

每个团队或者，如果代理部署需要使用本地工具，则需要将相同的库与其代理服务一起部署；而推送这些工具的更改则需要协调部署到每个使用这些工具的代理服务。实际上，许多团队为了避免协调开销，会直接独立地重新实现相同的工具。

Every team or agent deployment that wants to use local tools will need to deploy the same library along with their agent service, and pushing changes to these tools will require coordinating deployments to each agent service that uses these tools. In practice, many teams simply reimplement the same tools independently to avoid the coordination overhead.

维护

Maintenance

作为随着环境或需求的变化，手工打造的工具可能需要频繁的更新和调整。这种持续的维护工作会消耗大量资源，并且通常需要重新部署代理服务。

As the environment or requirements change, handcrafted tools may need frequent updates and adjustments. This ongoing maintenance can be resource-intensive and typically requires a redeployment of your agent service.

尽管存在这些缺点，手动精心制作的工具在解决传统弱点方面尤其有用。基础模型。简单的数学运算就是一个很好的例子。例如，单位换算、计算器运算、日历更改、日期和时间运算以及地图和图形运算，所有这些领域，手工打造的工具都能显著提高智能体的效率。

Despite these drawbacks, manually crafted tools are especially useful in addressing areas of traditional weakness for foundation models. Simple mathematical operations are a great example of this. Unit conversions, calculator operations, calendar changes, operations on dates and times, and operations over maps and graphs, for example, are all areas where handcrafted tools can substantially improve the efficacy of agentic systems.

我们来看一个例子：注册计算器工具。首先，我们定义一个简单的计算器功能：

Let’s look at an example of registering a calculator tool. First, we define our simple calculator function:

from langchain_core.runnables import ConfigurableField
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI

# Define tools using concise function definitions
@tool
def multiply(x: float, y: float) -> float:
   """Multiply 'x' times 'y'."""
   return x * y
`
@tool
def exponentiate(x: float, y: float) -> float:
   """Raise 'x' to the 'y'."""
   return x**y

@tool
def add(x: float, y: float) -> float:
   """Add 'x' and 'y'."""
   return x + y

然后，我们绑定LangChain 中基于基础模型的工具：

Then, we bind the tool with the foundation model in LangChain:

tools = [multiply, exponentiate, add]

# Initialize the LLM with GPT-4o and bind the tools
llm = ChatOpenAI(model_name="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools(tools)

这种“绑定”操作注册工具。在底层，LangChain 现在会检查基础模型的响应中是否包含调用工具的请求。现在我们已经绑定了工具，可以向基础模型提出问题，如果该工具有助于回答问题，基础模型将选择工具，选择这些工具的参数，并调用这些函数：

This “binding” operation registers the tool. Under the hood, LangChain will now check if the foundation model response includes any requests to call a tool. Now that we’ve bound the tool, we can ask the foundation model questions, and if the tool is helpful for answering the question, the foundation model will choose the tools, select the parameters for those tools, and invoke those functions:

query = "What is 393 * 12.25? Also, what is 11 + 49?"
messages = [HumanMessage(query)]

ai_msg = llm_with_tools.invoke(messages)
messages.append(ai_msg)
for tool_call in ai_msg.tool_calls:
   selected_tool = {"add": add, "multiply": multiply, 
       "exponentiate": exponentiate}[tool_call["name"].lower()]
   tool_msg = selected_tool.invoke(tool_call)
  
   print(f’{tool_msg.name} {tool_call['args']} {tool_msg.content}’)
   messages.append(tool_msg)
   final_response = llm_with_tools.invoke(messages)
   print(final_response.content)

通过添加这些用于可视化的打印语句，我们可以看到基础模型调用了两个函数——分别对应 `for`multiply和add`:`

With those added print statements for visibility, we can see that the foundation model invokes two function calls—one each for multiply and add:

multiply {'x': 393, 'y': 12.25} Result: 4814.25
add {'x': 11, 'y': 49} 60.0

然后，该模型会将工具调用的结果包含在生成的最终响应中，从而产生如下结果：

The model will then include this result from the tool call in the generated final response, producing a result such as:

393 times 12.25 is 4814.25, and 11 + 49 is 60.

虽然这种做法看似简单，但其意义却十分深远。基础模型现在能够执行我们绑定到它上面的计算机程序。这只是一个简单的例子，但我们可以将任意有用且影响深远的程序绑定到基础模型上，并且现在我们依靠基础模型来选择要执行哪些程序以及使用哪些参数。负责任地这样做，并且只绑定那些基础模型能够以利大于弊的方式执行的工具，才是明智之举。构建代理和代理系统的开发人员最重要的职责之一。

While the effect of this is simple, the implications are profound. The foundation model is now able to execute the computer programs that we bind with it. This is a simple example, but we can bind arbitrarily useful and consequential programs to the foundation model, and we now rely on the foundation model to choose which programs to execute with which parameters. Doing so responsibly, and only binding tools that the foundation model will execute in ways that produce more good than harm, is among the paramount responsibilities of developers building agents and agentic systems.

基于 API 的工具

API-Based Tools

基于 API 的工具使自主代理能够与……交互外部服务通过访问额外信息、处理数据和执行本地无法完成的操作来增强自身功能。这些工具利用应用程序编程接口 (API) 与公共或私有服务通信，从而提供了一种动态且可扩展的方式来扩展代理的功能。

API-based tools enable autonomous agents to interact with external services, enhancing their capabilities by accessing additional information, processing data, and executing actions that are not feasible to perform locally. These tools leverage application programming interfaces (APIs) to communicate with public or private services, providing a dynamic and scalable way to extend the functionality of an agent.

基于 API 的工具是在代理需要与各种外部系统集成、检索实时数据或执行复杂计算（这些计算如果由内部处理则资源消耗过大）的场景中，API 尤其有用。通过连接 API，代理可以访问各种服务，例如天气信息、股市数据、翻译服务等等，从而能够为用户查询提供更丰富、更准确的响应。这些基于 API 的工具具有诸多优势。

API-based tools are particularly valuable in scenarios where the agent needs to integrate with various external systems, retrieve real-time data, or perform complex computations that would be too resource-intensive to handle internally. By connecting to APIs, agents can access a vast array of services, such as weather information, stock market data, translation services, and more, enabling them to provide richer and more accurate responses to user queries. These API-based tools have multiple benefits.

通过利用外部服务，这些工具可以显著扩展智能体能够执行的任务范围。例如，智能体可以使用天气 API 提供当前天气状况和预报，使用金融 API 获取股票价格，或使用翻译 API 提供多语言支持。这种集成各种外部服务的能力极大地扩展了智能体的功能，而且无需重新训练模型。

By leveraging external services, these tools can dramatically expand the range of tasks an agent can perform. For instance, an agent can use a weather API to provide current weather conditions and forecasts, a financial API to fetch stock prices, or a translation API to offer multilingual support. This ability to integrate diverse external services greatly broadens the agent’s functionality, all without having to retrain a model.

实时数据访问是基于 API 的工具的另一大优势。API 使代理能够访问来自外部来源的最新信息，确保其响应和操作基于最新数据。这对于依赖及时准确信息的应用尤为重要，例如金融交易或应急响应系统，因为这些应用必须根据最新信息快速做出决策。可用数据。

Real-time data access is another major benefit of API-based tools. APIs enable agents to access the most current information from external sources, ensuring that their responses and actions are based on up-to-date data. This is particularly crucial for applications that depend on timely and accurate information, such as financial trading or emergency response systems, where decisions must be made quickly based on the latest available data.

举例说明在实现基于 API 的工具时，我们首先要让你的代理能够浏览开放网络以获取更多信息。在这段代码片段中，我们注册了一个从维基百科检索信息的工具，这是迈向完整网络浏览代理的第一步：

To illustrate the implementation of API-based tools, let’s begin with enabling your agent to browse the open web for additional information. In this code snippet, we register a tool to retrieve information from Wikipedia, a step toward a full web browsing agent:

from langchain_openai import ChatOpenAI
from langchain_community.tools import WikipediaQueryRun
from langchain_community.utilities import WikipediaAPIWrapper
from langchain_core.messages import HumanMessage

api_wrapper = WikipediaAPIWrapper(top_k_results=1, doc_content_chars_max=300)
tool = WikipediaQueryRun(api_wrapper=api_wrapper)

# Initialize the LLM with GPT-4o and bind the tools
llm = ChatOpenAI(model_name="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools([tool])

messages = [HumanMessage("What was the most impressive thing" +
                         "about Buzz Aldrin?")]

ai_msg = llm_with_tools.invoke(messages)
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:
   tool_msg = tool.invoke(tool_call)
  
   print(tool_msg.name)
   print(tool_call['args'])
   print(tool_msg.content)
   messages.append(tool_msg)
   print()

final_response = llm_with_tools.invoke(messages)
print(final_response.content)

基础模型会识别查询中感兴趣的对象，并在维基百科中搜索该术语。然后，它会利用这些额外信息来生成最终答案，从而回答问题：

The foundation model identifies the object of interest in the query and searches Wikipedia for the term. It then uses this additional information to generate its final answer when addressing the question:

{'query': '巴兹·奥尔德林'}
页码：巴兹·奥尔德林
摘要：巴兹·奥尔德林（Buzz Aldrin，原名小埃德温·尤金·奥尔德林，Edwin Eugene Aldrin Jr.，1930年1月20日出生）是一位
美国前宇航员、工程师和战斗机飞行员。他曾进行过三次太空行走。
他曾担任1966年双子星12号任务的飞行员，也是登月舱“鹰号”的飞行员。
1969 年阿波罗 11 号任务。

巴兹·奥尔德林最令人印象深刻的一点是，他是月球人。
他是1969年阿波罗11号任务中“鹰”号舱的驾驶员，也是最早一批……之一。
两名人类首次登上月球。这一历史性事件标志着一个重要的里程碑。
奥尔德林在太空探索和人类历史上取得了卓越成就。此外，奥尔德林还取得了其他成就。
作为1966年双子星12号任务的飞行员，他进行了三次太空行走，展示了他的工具。
并为推进太空旅行做出了贡献。

现在我们来看第二个例子，一个用于获取和显示股票市场数据的代理。这个过程包括定义 API 交互、处理响应以及将该工具集成到代理的工作流程中。通过这种方法，代理可以无缝集成外部数据源，从而增强其整体功能和效率。

Let’s now look at a second example, for an agent that is designed to fetch and display stock market data. This process involves defining the API interaction, handling the response, and integrating the tool into the agent’s workflow. By following this approach, agents can integrate external data sources seamlessly, enhancing their overall functionality and effectiveness.

首先，我们定义函数它与股票市场 API 进行交互。然后，我们将此函数注册为代理的工具，之后我们就可以像调用之前的工具一样调用它：

First, we define the function that interacts with the stock market API. Then, we register this function as a tool for our agent, and we can then invoke it just like the previous tools:

from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langchain_community.tools import WikipediaQueryRun
from langchain_community.utilities import WikipediaAPIWrapper
from langchain_core.messages import HumanMessage
import requests

@tool
def get_stock_price(ticker: str) -> float:
   """Get the stock price for the stock exchange ticker for the company."""
   api_url = f"https://api.example.com/stocks/{ticker}"
   response = requests.get(api_url)
   if response.status_code == 200:
       data = response.json()
       return data["price"]
   else:
       raise ValueError(f"Failed to fetch stock price for {ticker}")


# Initialize the LLM with GPT-4o and bind the tools
llm = ChatOpenAI(model_name="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools([get_stock_price])

messages = [HumanMessage("What is the stock price of Apple?")]

ai_msg = llm_with_tools.invoke(messages)
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:
   tool_msg = get_stock_price.invoke(tool_call)
  
   print(tool_msg.name)
   print(tool_call['args'])
   print(tool_msg.content)
   messages.append(tool_msg)
   print()

final_response = llm_with_tools.invoke(messages)
print(final_response.content)

类似的工具也可用于搜索团队或公司特定的信息。通过为代理提供访问处理任务所需信息的工具，以及操作这些信息的特定工具，您可以显著扩展可自动化任务的范围和复杂性。

Similar tools can be created to search across team- or company-specific information. By providing your agent with the tools necessary to access the information it needs to handle a task, and the specific tools to operate over that information, you can significantly expand the scope and complexity of tasks that can be automated.

在设计时代理的 API 工具应注重可靠性、安全性和优雅的故障处理。外部服务可能会出现故障，因此代理需要备用方案或清晰的错误信息。所有通信，尤其是敏感数据，都应使用 HTTPS 和强身份验证来保护。

When designing API tools for agents, focus on reliability, security, and graceful failure. External services can go down, so agents need fallbacks or clear error messages. Secure all communications with HTTPS and strong authentication, especially for sensitive data.

注意 API 速率限制以避免服务中断，并确保遵守数据隐私法律——必要时对用户数据进行匿名化或混淆处理。妥善处理错误，以便代理程序能够从网络问题或无效响应中恢复，而不会影响用户体验。如果某个提供商的性能下降，请尽可能考虑使用替代方案和多个提供商以提高可靠性。

Watch out for API rate limits to avoid disruptions, and ensure compliance with data privacy laws—anonymize or obfuscate user data when needed. Handle errors robustly so the agent can recover from network issues or invalid responses without breaking the user experience. When possible, consider alternatives and multiple providers for greater reliability if any given provider is degraded.

API 为代理提供实时数据、强大的计算能力以及它们自身无法执行的外部操作，从而大大增强了它们的能力。而且有效。

APIs empower agents with real-time data, heavy computation, and external actions they couldn’t perform alone, making them far more capable and effective.

插件工具

Plug-In Tools

这些工具是这些模块化工具只需极少的定制即可集成到人工智能代理的框架中。它们利用现有的库、API 和第三方服务来扩展代理的功能，而无需大量的开发工作。插件工具能够快速部署和扩展代理的功能。这些工具是预先设计的模块，可以利用现有的库、API 和第三方服务，以极少的工作量集成到人工智能系统中。插件工具的集成已成为 OpenAI、Anthropic 的 Claude、Google 的 Gemini 和 Microsoft 的 Phi 等领先平台以及不断壮大的开源社区的标准配置。插件工具提供了强大的工具，无需大量的自定义开发即可扩展人工智能代理的功能。

These tools are modular and can be integrated into the AI agent’s framework with minimal customization. They leverage existing libraries, APIs, and third-party services to extend the agent’s capabilities without extensive development effort. Plug-in tools enable rapid deployment and scaling of the agent’s functionalities. These tools are predesigned modules that can be integrated into an AI system with minimal effort, leveraging existing libraries, APIs, and third-party services. The integration of plug-in tools has become a standard offering from leading platforms such as OpenAI, Anthropic’s Claude, Google’s Gemini, and Microsoft’s Phi as well as a growing open source community. Plug-in tools provide powerful tools to expand the capabilities of AI agents without extensive custom development.

OpenAI 的插件生态系统提供强大的扩展功能，涵盖从实时网页搜索到专用代码生成器等各种功能，但这些功能仅在 ChatGPT 产品内部可用，无法通过公共 API 使用。您无法通过标准的 OpenAI Completions 或 Chat端点调用 Expedia、Zapier 或任何 ChatGPT 第一方插件。要在您自己的应用程序中实现类似功能，您必须构建自定义函数调用层（例如，通过 LangChain），以近似实现插件的功能。

OpenAI’s plug-ins ecosystem offers powerful extensions—everything from real-time web search to specialized code generators—but they’re only available inside the ChatGPT product, not the public API. You cannot invoke Expedia, Zapier, or any first-party ChatGPT plug-in through the standard OpenAI Completions or Chat endpoints. To replicate similar behavior in your own applications, you must build custom function-calling layers (for example, via LangChain) that approximate plug-in functionality.

人格的克劳德相比之下，Claude 通过 Anthropic Messages API（以及 Amazon Bedrock 或 Google Cloud 的 Vertex AI 等平台）直接开放其完整的“工具使用”功能。您只需注册自定义工具（或使用 Anthropic 提供的工具），Claude 即可在推理时调用它们——无需单独的用户界面。这种 API 优先的方法使得将内容审核、偏见检测或特定领域服务集成到任何基于 Claude 的工作流程中变得非常简单。

Anthropic’s Claude, by contrast, exposes its full “tool use” capability directly through the Anthropic Messages API (and on platforms like Amazon Bedrock or Google Cloud’s Vertex AI). You simply register your custom tools (or use Anthropic-provided ones), and Claude can call them at inference time—no separate UI required. This API-first approach makes it straightforward to integrate content moderation, bias detection, or domain-specific services into any Claude-powered workflow.

谷歌的双子座计划模型支持通过 Vertex AI API 进行函数调用，允许您在代码中声明工具FunctionCallingConfig，并让 Gemini 以结构化调用的方式调用它们。无论您需要自然语言理解、图像识别还是数据库查找，您都可以预先定义函数，并在代码中处理返回的参数——您的应用程序和模型之间没有任何专有 UI 层。

Google’s Gemini models support function calling via the Vertex AI API, letting you declare tools in a FunctionCallingConfig and have Gemini invoke them as structured calls. Whether you need natural language understanding, image recognition, or database lookups, you define the functions up front and process the returned arguments in your code—no proprietary UI layer stands between your app and the model.

微软的 Phi这些模型通过 Azure AI Foundry 提供，并可通过与其他 Azure AI 模型相同的公共终结点，与其他 Azure 服务（例如认知搜索、文档处理和数据可视化 API）无缝集成。虽然 Phi 并未被命名为“插件”，但它与 Azure 生产力和分析工具的紧密集成，带来了同样流畅的体验：您可以调用模型、接收结构化输出，并将其直接导入到现有的 Azure 工作流中，而无需切换上下文。

Microsoft’s Phi models are offered through Azure AI Foundry, where they integrate seamlessly with other Azure services—such as cognitive search, document processing, and data visualization APIs—via the same public endpoints you use for other Azure AI models. Though not branded as “plug-ins,” Phi’s tight coupling with Azure’s productivity and analytics tools delivers a similarly smooth experience: you call the model, receive structured outputs, and feed them directly into your existing Azure workflows without switching contexts.

其中一个显著优势是插件工具的优势在于其与模型执行层的集成。这意味着这些工具可以添加到人工智能模型中，对现有工作流程的干扰极小。开发人员只需将这些模块插入到他们的人工智能系统中，即可立即增强其功能，而无需进行大量的定制或开发工作。这种易于集成的特性使得插件工具成为在人工智能应用中快速部署新功能的理想选择。然而，这种易用性也带来了一些局限性。插件工具虽然功能强大，但其可定制性和适应性不如可本地或远程部署的定制开发工具。它们被设计为通用工具，可以处理各种任务，但可能无法满足每个应用程序的特定需求和细微差别。在插件工具和定制开发之间进行选择时，开发人员需要权衡易于集成和可定制性之间的利弊。

One of the significant advantages of plug-in tools is their integration at the model execution layer. This means these tools can be added to AI models with minimal disruption to existing workflows. Developers can simply plug these modules into their AI systems, instantly enhancing their capabilities without extensive customization or development effort. This ease of integration makes plug-in tools an attractive option for rapidly deploying new functionalities in AI applications. However, this ease of use comes with certain limitations. Plug-in tools, while powerful, do not offer the same level of customizability and adaptability as custom-developed tools that can be served either locally or remotely. They are designed to be general-purpose tools that can address a broad range of tasks, but they may not be tailored to the specific needs and nuances of every application. This trade-off between ease of integration and customizability is an important consideration for developers when choosing between plug-in tools and bespoke development.

尽管目前存在局限性，但目录主流平台提供的插件工具数量正在迅速增长。随着这些工具目录的扩展，插件工具的功能范围也将不断扩大，为开发者提供更多增强人工智能代理的工具。这一增长得益于人工智能研究的持续进步以及新技术和新方法的开发。在不久的将来，我们可以预期这些插件工具目录将包含更多专业化和高级功能，以满足更广泛的应用和行业需求。这种扩展将为开发者提供现成的工具来应对复杂多样的任务，从而促进代理的开发。不断壮大的插件工具生态系统将使人工智能代理能够执行日益复杂的功能，使其在各个领域更加灵活高效。

Despite the current limitations, the catalogs of plug-in tools offered by leading platforms are rapidly growing. As these catalogs expand, the breadth of capabilities available through plug-in tools will increase, providing developers with even more tools to enhance their AI agents. This growth is driven by continuous advancements in AI research and the development of new techniques and technologies. In the near future, we can expect these plug-in tool catalogs to include more specialized and advanced functionalities, catering to a wider range of applications and industries. This expansion will facilitate agent development by providing developers with readily available tools to address complex and diverse tasks. The growing ecosystem of plug-in tools will enable AI agents to perform increasingly sophisticated functions, making them more versatile and effective in various domains.

除了主要平台提供的服务之外，还有一个快速增长的工具生态系统可以集成到系统中。开源基础模型。该生态系统为希望增强其人工智能代理高级功能的开发者提供了丰富的资源。开源社区积极参与插件工具的开发，营造了促进创新和知识共享的协作环境。一个值得注意的例子是 Hugging Face Transformers 库，它提供了一系列用于自然语言处理任务的预训练模型和插件工具。这些工具可以轻松集成到开源基础模型中，从而实现文本生成、情感分析和语言翻译等功能。该库的开源特性使开发者能够根据自身特定需求定制和扩展这些工具。这些框架的灵活性意味着开发者可以将插件工具与自定义开发相结合，从而创建强大且适应性强的人工智能系统。在研究人员、开发者和爱好者的共同努力下，开源人工智能社区不断贡献新的插件工具和增强功能。Glama.ai和mcp.so等平台聚合了大量的 MCP 服务器，使其可搜索和发现，涵盖了从简单的实用程序到复杂的有状态服务的各种应用。这些贡献丰富了生态系统，并为希望利用人工智能最新进展的开发人员提供了宝贵的资源。

In addition to the offerings from major platforms, there is a rapidly growing ecosystem of tools that can be incorporated into open source foundation models. This ecosystem provides a wealth of resources for developers looking to enhance their AI agents with advanced capabilities. Open source communities are actively contributing to the development of plug-in tools, creating a collaborative environment that fosters innovation and knowledge sharing. One notable example is the Hugging Face Transformers library, which offers a wide range of pretrained models and plug-in tools for natural language processing tasks. These tools can be easily integrated into open source foundation models, enabling functionalities such as text generation, sentiment analysis, and language translation. The open source nature of this library enables developers to customize and extend these tools to suit their specific needs. The flexibility of these frameworks means that developers can combine plug-in tools with custom development, creating powerful and adaptable AI systems. The open source AI community is continuously contributing new plug-in tools and enhancements, driven by the collective efforts of researchers, developers, and enthusiasts. Platforms like Glama.ai, and mcp.so aggregate large numbers of MCP servers, making them searchable and discoverable, ranging from simple utilities to complex, stateful services. These contributions enrich the ecosystem and provide valuable resources for developers looking to leverage the latest advancements in AI.

实际应用插件工具种类繁多，涵盖多个行业和应用场景。通过集成这些插件工具，开发者可以创建高效执行各种任务的人工智能代理。在客户支持领域，插件工具可以帮助人工智能代理处理查询、提供解决方案并管理支持工单。自然语言理解和情感分析等工具可以帮助人工智能代理理解客户问题并做出恰当的回应，从而提高客户满意度并缩短响应时间。在医疗保健领域，插件工具可以辅助人工智能代理完成诸如医学图像分析、患者分诊和数据管理等任务。利用计算机视觉的工具可以帮助识别医学图像中的异常情况，自然语言处理工具可以帮助管理患者记录并从医学文献中提取相关信息，而向量搜索工具则可以提供相关文档的依据来解决当前查询。在金融行业，插件工具可以增强人工智能代理分析市场趋势、检测欺诈活动和管理金融投资组合的能力。异常检测和预测分析等工具可以提供有价值的洞察并改进决策流程。在教育领域，插件工具可以支持人工智能代理进行个性化学习、自动评分和内容推荐。

The practical applications of plug-in tools are vast and varied, spanning multiple industries and use cases. By integrating plug-in tools, developers can create AI agents that perform a wide range of tasks efficiently and effectively. In customer support, plug-in tools can enable AI agents to handle queries, provide solutions, and manage support tickets. Tools like natural language understanding and sentiment analysis can help AI agents understand customer issues and respond appropriately, improving customer satisfaction and reducing response times. In healthcare, plug-in tools can assist AI agents in tasks such as medical image analysis, patient triage, and data management. Tools that leverage computer vision can help identify abnormalities in medical images, while natural language processing tools can assist in managing patient records and extracting relevant information from medical literature, and vector search tools can offer grounding in relevant documents to address the current query. In the finance industry, plug-in tools can enhance AI agents’ abilities to analyze market trends, detect fraudulent activities, and manage financial portfolios. Tools like anomaly detection and predictive analytics can provide valuable insights and improve decision-making processes. In education, plug-in tools can support AI agents in personalized learning, automated grading, and content recommendation.

插件工具的未来人工智能（AI）的发展前景一片光明，持续进步，并在各个行业得到越来越广泛的应用。随着插件工具功能的扩展，我们可以期待AI代理变得更加强大和灵活。领先平台和开源社区持续不断的研发努力将推动创新，从而催生出更强大、更精密的AI开发工具。未来一个重要的关注点是插件工具的互操作性和标准化。为插件工具建立通用标准和协议将有助于不同AI平台和系统之间的无缝集成和互操作。这将使开发人员能够利用来自不同来源的插件工具，从而创建更灵活、更具适应性的AI解决方案。目前也在努力增强插件工具的定制性和适应性。未来的插件工具可能会提供更多可配置选项，使开发人员能够根据特定的用例和需求进行定制。这将弥合集成便捷性和定制化解决方案需求之间的差距，从而提供最佳解决方案。两个世界。

The future of plug-in tools in AI development looks promising, with continuous advancements and growing adoption across various industries. As the capabilities of plug-in tools expand, we can expect AI agents to become even more capable and versatile. The ongoing research and development efforts by leading platforms and the open source community will drive innovation, resulting in more powerful and sophisticated tools for AI development. One important area of focus for the future is the interoperability and standardization of plug-in tools. Establishing common standards and protocols for plug-in tools will facilitate seamless integration and interoperability across different AI platforms and systems. This will enable developers to leverage plug-in tools from various sources, creating more flexible and adaptable AI solutions. Efforts are also being made to enhance the customization and adaptability of plug-in tools. Future plug-in tools may offer more configurable options, enabling developers to tailor them to specific use cases and requirements. This will bridge the gap between the ease of integration and the need for customized solutions, providing the best of both worlds.

模型上下文协议

Model Context Protocol

人工智能随着生态系统的成熟，智能体不再孤立运行。它们需要从云存储读取文档、将数据推送至业务应用程序、调用内部 API 并与其他智能体协作。自定义集成——即为每个数据源或服务编写定制适配器——既脆弱又难以扩展。模型上下文协议 (MCP) 应运而生：这是由 Anthropic 推出的开放标准（此后已被 OpenAI、Google DeepMind 和 Microsoft 等主要厂商采用），它提供了一种统一的、与模型无关的方式，将逻辑逻辑模型 (LLM) 连接到外部系统。可以将 MCP 视为“人工智能的 USB-C 接口”——一个单一且定义明确的接口，任何数据源或工具都可以公开该接口，任何智能体都可以使用它，而无需编写专门的粘合代码。MCP 的核心定义了两个角色：

As the AI ecosystem matures, agents no longer live in isolated silos. They need to read documents from cloud storage, push data to business applications, call internal APIs, and coordinate with other agents. Custom integrations—where you write bespoke adapters for each data source or service—are brittle and scale poorly. Enter the Model Context Protocol (MCP): an open standard introduced by Anthropic (and since adopted by major players like OpenAI, Google DeepMind, and Microsoft) that provides a uniform, model-agnostic way to connect LLMs to external systems. Think of MCP as a “USB-C port for AI”—a single, well-defined interface that any data source or tool can expose, and any agent can consume, without specialized glue code. At its core, MCP defines two roles:

MCP服务器

MCP server

这是一个通过标准化的 JSON-RPC 2.0 接口公开数据或服务的 Web 服务器。只要实现了 MCP 规范，服务器可以封装任何内容——云对象存储、SQL 数据库、企业客户关系管理、专有业务逻辑等等。

This is a web server that exposes data or services via a standardized JSON-RPC 2.0 interface. A server can wrap anything—cloud object storage, SQL databases, enterprise customer relationship management, proprietary business logic—so long as it implements the MCP specification.

MCP客户端

MCP client

任何支持 MCP 协议的代理或 LLM 应用程序都适用此协议。客户端发送 JSON-RPC 请求（例如，“列出此 Salesforce 文件夹中的所有文件”或“使用 customerId=1234 执行函数 'getCustomerBalance'”），并接收结构化的 JSON 响应。由于协议统一，代理开发人员无需了解服务器内部机制，只需了解其公开的方法即可。

This is any agent or LLM application that “speaks” MCP. The client sends JSON-RPC requests (e.g., “List all files in this Salesforce folder,” or “Execute function ‘getCustomerBalance’ with customerId=1234”) and receives structured JSON responses. Because the protocol is uniform, an agent developer doesn’t need to know the internals of the server—only its exposed methods.

MCP 底层使用基于 HTTPS 或 WebSocket 的 JSON-RPC 2.0。服务器会发布其可用方法（例如 `get`、listFiles`get`、getRecord`get` runAnalysis）及其输入/输出模式。客户端获取服务器的“方法目录”，以便 LLM 能够推断出要调用哪个方法以及使用哪些参数。一旦选定工具调用，MCP 客户端会将该调用封装到 JSON-RPC 有效负载中，并将其发送到相应的服务器，然后等待响应。由于两端使用相同的语言，因此构建跨平台互操作性变得非常简单。

Under the hood, MCP uses JSON-RPC 2.0 over HTTPS or WebSocket. Servers advertise their available methods (e.g., listFiles, getRecord, runAnalysis) and their input/output schemas. Clients fetch the server’s “method catalog,” allowing an LLM to reason about which method to call and with what parameters. Once the tool call is chosen, the MCP client wraps that call into a JSON-RPC payload, sends it over to the appropriate server, and awaits a response. Because both ends speak the same language, building cross-platform interoperability becomes straightforward.

在 MCP 出现之前，开发人员需要为每个目标系统编写自定义适配器，直接在代理代码中硬编码 REST 调用或 SDK 使用。随着数据源数量的增长，这些定制集成也成倍增加，导致代码脆弱、容易出错，难以维护。维持或延长。

Before MCP, developers wrote custom adapters for each target system—hard-coding REST calls or SDK usage directly inside their agent code. As the number of data sources grew, these bespoke integrations multiplied, resulting in brittle, error-prone code that was difficult to maintain or extend.

尽管有这些优势，但仍存在一些问题。安全问题已被提出，但尚未得到充分解决——尤其是在多个代理共享 MCP 端点时，身份验证、访问控制和潜在攻击途径等方面。确保只有授权代理才能调用特定方法、维护基于角色的敏感数据访问控制、防止恶意载荷注入以及维护审计日志，仍然是当前研究和工程的重点领域。一些组织仍然依赖额外的网络策略或代理层来降低这些风险，但 MCP 核心规范尚未强制要求采用单一的标准化安全解决方案。尽管如此，MCP 解决了跨多个代理重用工具的关键挑战：一旦服务通过 MCP 公开，任意数量的代理都可以发现并调用其方法，而无需为每个代理重写自定义适配器。这极大地减少了开发工作量，并鼓励采用模块化、可重用的架构。

Despite these advantages, several security issues have been raised and are not yet fully addressed—particularly around authentication, access controls, and potential attack vectors when multiple agents share MCP endpoints. Ensuring that only authorized agents invoke specific methods, maintaining role-based access control to sensitive data, preventing malicious payload injection, and maintaining audit logs remain active areas of research and engineering. Some organizations still rely on additional network policies or proxy layers to mitigate these risks, but the core MCP specification does not yet mandate a single, standardized security solution. Nevertheless, MCP solves a critical challenge of tool reuse across multiple agents: once a service is exposed via MCP, any number of agents can discover and invoke its methods without rewriting custom adapters for each agent. This dramatically reduces development effort and encourages modular, reusable architectures.

要在 MCP 中查看接下来，我们将通过一个完整的 Python 示例来演示以下操作：

To see MCP in action, we’ll walk through a self-contained Python example that does the following:

1. 启动本地“数学”MCP服务器（通过子进程）

2. Launches a local “math” MCP server (via a subprocess)

3. 连接到运行在localhost:8000/mcp上的远程“天气”MCP 服务器

4. Connects to a remote “weather” MCP server running on localhost:8000/mcp

5. 实现异步代理循环，检查用户的最后一条消息，并决定是调用“数学”工具（用于算术表达式）还是“天气”工具（用于天气查询）。

6. Implements an asynchronous agent loop that inspects the user’s last message and decides whether to call the “math” tool (for arithmetic expressions) or the “weather” tool (for weather queries)

7. 演示代理如何解析工具的输出并返回最终的助手响应

8. Demonstrates how the agent parses the tool’s output and returns a final assistant response

以下是演示这些步骤的完整 Python 实现：

Here’s the complete Python implementation demonstrating these steps:

class AgentState(TypedDict):
    messages: Sequence[Any]  # A list of BaseMessage/HumanMessage/...

mcp_client = MultiServerMCPClient(
    {
        "math": {
            "command": "python3",
            "args": ["src/common/mcp/MCP_weather_server.py"],
            "transport": "stdio",  # Subprocess → STDIO JSON-RPC
        },
        "weather": {
            # Assumes a separate MCP server is already running on port 8000
            "url": "http://localhost:8000/mcp",
            "transport": "streamable_http",  
            # HTTP→JSON-RPC over WebSocket/stream
        },
    }
)

async def get_mcp_tools() -> list[Tool]:
    return await mcp_client.get_tools()

async def call_mcp_tools(state: AgentState) -> dict[str, Any]:
    messages = state["messages"]
    last_msg = messages[-1].content.lower()

    # Fetch and cache MCP tools on the first call
    global MCP_TOOLS
    if "MCP_TOOLS" not in globals():
        MCP_TOOLS = await mcp_client.get_tools()

    # Simple heuristic: if any digit-operator token appears, choose "math"
    if any(token in last_msg for token in ["+", "-", "*", "/", "(", ")"]):
        tool_name = "math"
    elif "weather" in last_msg:
        tool_name = "weather"
    else:
        # No match → respond directly
        return {
            "messages": [
                {
                    "role": "assistant",
                    "Sorry, I can only answer math" + 
                        " or weather queries." 
                }
            ]
        }

    tool_obj = next(t for t in MCP_TOOLS if t.name == tool_name)

    user_input = messages[-1].content
    mcp_result: str = await tool_obj.arun(user_input)

    return {
        "messages": [
            {"role": "assistant", "content": mcp_result}
        ]
    }

该"math"条目使用command+args来生成一个运行MCP_weather_server.py的子进程。该脚本底层必须符合 MCP 规范（即，通过 STDIO 提供 JSON-RPC 服务）。

The "math" entry uses command + args to spawn a subprocess that runs MCP_weather_server.py. Under the hood, this script must conform to MCP (i.e., serve JSON-RPC over STDIO).

该"weather"入口指向一个已在http://localhost:8000/mcp上运行的 HTTP MCP 服务器。该streamable_http传输方式支持双工 JSON-RPC 通信。通过 HTTP/WebSocket。

The "weather" entry points to an already running HTTP MCP server at http://localhost:8000/mcp. The streamable_http transport allows duplex JSON-RPC communication over HTTP/WebSocket.

MCP 代表着重要的MCP 在大规模设计、部署和维护 AI 代理方面迈出了重要一步。它定义了一个统一的、标准化的 JSON-RPC 接口来公开和使用方法，从而将服务实现与代理逻辑解耦，使得任意数量的代理无需定制集成即可重用相同的工具。实际上，这意味着随着新的数据源、微服务或遗留系统的出现，开发人员只需实现一次符合 MCP 标准的服务器，任何支持 MCP 的代理都可以立即发现并调用其方法。

MCP represents a significant step forward in how we design, deploy, and maintain AI agents at scale. By defining a single, standardized JSON-RPC interface for exposing and consuming methods, MCP decouples service implementation from agent logic, enabling any number of agents to reuse the same tools without bespoke integrations. In practice, this means that as new data sources, microservices, or legacy systems emerge, developers need only implement an MCP-compliant server once—and any MCP-capable agent can discover and invoke its methods immediately.

尽管诸如强大的身份验证、细粒度的访问控制和有效载荷验证等安全问题仍处于积极的开发阶段，但MCP的核心优势——无缝互操作性和模块化工具重用——已在领先企业的生产系统中得到实现。展望未来，我们期待MCP的安全最佳实践不断完善，标准化方法目录得到更广泛的应用，以及公共和私有MCP端点生态系统的不断发展壮大。总之，MCP解决了智能体系统设计中最棘手的难题之一——如何快速可靠地集成各种服务——同时为构建更加灵活、易于维护和分布式的AI架构奠定了基础。

Although security concerns like robust authentication, fine-grained access control, and payload validation remain active areas of development, the core promise of MCP—seamless interoperability and modular tool reuse—has already been realized in production systems across leading organizations. Looking ahead, we expect continued refinement of MCP’s security best practices, broader adoption of standardized method catalogs, and the growth of an ecosystem of public and private MCP endpoints. In sum, MCP solves one of the most persistent challenges in agentic system design—how to integrate diverse services quickly and reliably—while laying a foundation for ever more flexible, maintainable, and distributed AI architectures.

状态工具

Stateful Tools

有状态工具它们涵盖本地脚本、外部 API 和 MCP 部署的服务，但它们都面临着一个共同的风险：当你将直接权力交给基础模型时，就会发生这种情况。持久状态也意味着它更容易犯下破坏性错误，或被恶意行为者利用。在某个真实案例中，人工智能代理通过删除生产表中一半的行来“优化”数据库性能，在此过程中抹去了关键记录。即使没有恶意，基础模型也可能误解用户的意图，将原本无害的查询变成破坏性命令。对于有状态工具而言，这种风险尤为突出，因为它们会与内容随时间变化的实时数据存储进行交互。

Stateful tools span local scripts, external APIs, and MCP‐deployed services, yet they all share a common risk: when you hand a foundation model direct power over persistent state, you also empower it to make destructive mistakes or to be exploited by bad actors. In one real-world case, an AI agent “optimized” database performance by dropping half the rows from a production table, erasing critical records in the process. Even without malice, foundation models can misinterpret a user’s intent, turning what should be a harmless query into a destructive command. This risk is especially acute for stateful tools because they interact with live data stores whose contents change over time.

为了降低这些风险，应仅将范围狭窄的操作注册为工具，而不是暴露“执行任意 SQL”端点。例如，定义一个工具或一个工具，每个工具都封装一个经过充分测试的查询或过程。仅需读取权限的代理绝不应获得删除或修改数据的权限。通过在注册层限制工具的功能，可以显著缩小攻击面并限制潜在错误的范围。get_user_​profile(user_id)add_new_customer(record)

To mitigate these dangers, register only narrowly scoped operations as tools instead of exposing an “execute arbitrary SQL” endpoint. For example, define a get_user_​profile(user_id) tool or an add_new_customer(record) tool, each encapsulating a single, well-tested query or procedure. Agents needing only read access should never receive rights to delete or modify data. By constraining tool capabilities at the registration layer, you sharply reduce the attack surface and limit the scope of potential errors.

如果您的使用场景确实需要自由格式查询，则必须实施严格的清理和访问控制。OWASP 的 GenAI 安全项目警告说，提示注入可能会将危险的子句（例如 ` DROPif` 或 `if` ）注入ALTER到原本无害的请求中，因此输入验证必须拒绝任何包含这些模式的语句。始终绑定参数或使用预处理语句来防止 SQL 注入，并确保代理使用的数据库帐户仅拥有执行允许查询所需的最低权限。

If your use case absolutely demands free-form queries, you must implement rigorous sanitization and access controls. OWASP’s GenAI Security Project warns that prompt injections can slip dangerous clauses like DROP or ALTER into otherwise benign requests, so input validation must reject any statement containing these patterns. Always bind parameters or use prepared statements to prevent SQL injection, and ensure the database account used by the agent holds only the minimum privileges needed to execute the allowed queries.

除了消毒之外，还要记录每一种工具强烈建议启用异常行为检测和取证分析功能。结合针对可疑模式（例如异常大幅度删除或修改模式的命令）的实时警报，您可以迅速介入，防止小错误演变成重大事件。

Beyond sanitization, logging every tool invocation to detect anomalous behavior and support forensic analysis is highly recommended. Coupled with real-time alerts for suspicious patterns—such as unusually large deletions or schema-altering commands—you can intervene quickly before small errors cascade into major incidents.

最终，最小权限原则应指导您的设计：仅赋予模型其绝对必要的工具，并用精确的边界和监督来保护每一项操作。无论您的工具是在本地运行、调用外部 API 还是在 MCP 服务器上执行，同样的保障措施都适用——限制功能、清理输入、强制执行最小权限原则并保持完全可观测性。通过以这种程度的约束来管理有状态工具，您可以确保您的 AI 代理始终是强大的协作伙伴，而不是不受控制的数据库。管理员。

Ultimately, the principle of least power should guide your design: give the model only the tools it strictly requires, and guard every operation with precise boundaries and oversight. Whether your tool runs locally, calls an external API, or executes on an MCP server, the same safeguards apply—restrict capabilities, sanitize inputs, enforce least privilege, and maintain full observability. By treating stateful tools with this level of discipline, you ensure that your AI agents remain powerful collaborators rather than uncontrolled database administrators.

基础模型作为工具制造者

Foundation Models as Tool Makers

基础模型无它们不再只是工具的使用者，而是工具的构建者。通过向 LLM 提供 API 规范或示例输入，您可以让它生成初始包装器、辅助函数或更高级别的“原子”操作。让模型生成代码存根，在安全的沙箱环境中执行，然后评估自身的输出：“该端点返回了 400 错误——请调整查询参数。” 经过几次快速迭代，您最终将获得一套经过充分测试、范围明确的工具，代理可以直接调用这些工具，而无需手动编写每个包装器。

Foundation models no longer just consume tools—they build them. By feeding an LLM your API specifications or sample inputs, you can have it generate initial wrappers, helper functions, or higher-level “atomic” operations. Let the model draft code stubs, execute them in a safe sandbox, and then critique its own output: “That endpoint returned a 400—adjust the query parameters.” Over a few rapid iterations, you end up with a suite of well-tested, narrowly scoped tools that agents can call directly, without crafting every wrapper by hand.

当您需要处理庞大的 API 环境时，这种方法优势显著。您无需手动编写数十个微服务客户端，只需将模型指向您的 OpenAPI 规范（或代码示例），它就能自动生成每个函数的初稿。之后，人工审核人员会在代码进入持续集成/持续部署 (CI/CD) 流水线之前对其进行验证和优化，从而确保安全性和正确性。随着 API 的演进，您只需重新运行相同的生成和优化循环，即可保持工具同步——这不仅节省了数周的样板代码编写时间，还避免了编写脆弱的、手写的粘合代码。

This approach shines when you’re wrestling with a sprawling API landscape. Instead of manually writing dozens of microservice clients, you point the model at your OpenAPI spec (or code samples) and let it spin up a first draft of each function. Human reviewers then validate and tighten the generated code before it enters your continuous integration/continuous deployment (CI/CD) pipeline, ensuring security and correctness. As your APIs evolve, you simply rerun the same generate-and-refine loop to keep your tools in sync—saving weeks of boilerplate work and avoiding brittle, handwritten glue code.

虽然基于基础架构的工具创建能够大幅缩短开发时间并轻松扩展，但它仍然需要清晰的验证标准（测试、响应检查、模式强制执行）和开发人员的监督。模型的自然语言评论使任何建议的修复都易于理解，但您最终仍需负责捕获极端情况、防范安全漏洞并确认业务逻辑的一致性。如果运用得当，这种人工智能创造力与人工审核相结合的方式可以将错综复杂的 API 生态系统转变为精简的、可立即投入使用的工具包，从而实现快速、可靠的应用开发。实现组织内部的自动化。

While foundation-driven tool creation slashes development time and scales effortlessly, it still demands clear validation criteria (tests, response checks, schema enforcement) and developer oversight. The model’s natural language critiques make it easy to understand any recommended fixes, but you’re ultimately responsible for catching edge cases, guarding against security gaps, and confirming business logic alignment. When done right, this hybrid of AI creativity and human review transforms a tangled API ecosystem into a lean, agent-ready toolkit—unlocking rapid, reliable automation across your organization.

实时代码生成

Real-Time Code Generation

实时代码代码生成是指人工智能代理在运行过程中根据需要编写和执行代码。这种能力使代理能够创建新工具或修改现有工具以应对特定任务，从而具备高度的适应性。例如，如果人工智能代理遇到新的API或不熟悉的问题，它可以实时生成代码来与该API交互或开发问题的解决方案。

Real-time code generation involves an AI agent writing and executing code as needed during its operation. This capability enables the agent to create new tools or modify existing ones to address specific tasks, making it highly adaptable. For instance, if an AI agent encounters a novel API or an unfamiliar problem, it can generate code to interface with the API or develop a solution to the problem in real time.

该过程始于智能体分析当前任务并确定完成任务所需的步骤。基于理解，智能体编写代码片段并尝试执行。如果代码未按预期运行，智能体会迭代地修改代码，从每次尝试中学习，直到达到预期结果。这种反复试错的迭代过程使智能体能够不断改进其工具，从而自主地提高性能并扩展功能。

The process begins with the agent analyzing the task at hand and determining the necessary steps to accomplish it. Based on its understanding, the agent writes code snippets, which it then attempts to execute. If the code does not perform as expected, the agent iteratively revises it, learning from each attempt until it achieves the desired outcome. This iterative process of trial and error enables the agent to refine its tools continuously, improving its performance and expanding its capabilities autonomously.

实时代码生成具有诸多显著优势，尤其是在适应性和效率方面。即时生成代码的能力使人工智能代理能够快速适应新的任务和环境。这种适应性对于需要动态问题解决和灵活性的应用至关重要，例如实时数据分析和复杂的软件集成任务。通过实时生成代码，人工智能代理无需等待人工干预即可满足即时需求，从而显著加快流程、减少停机时间并提高整体效率。

Real-time code generation offers several compelling advantages, particularly in terms of adaptability and efficiency. The ability to generate code on-the-fly enables AI agents to quickly adapt to new tasks and environments. This adaptability is crucial for applications requiring dynamic problem-solving and flexibility, such as real-time data analysis and complex software integration tasks. By generating code in real time, AI agents can address immediate needs without waiting for human intervention, significantly speeding up processes, reducing downtime, and enhancing overall efficiency.

然而，实时代码生成也带来了一些挑战和风险。质量控制是主要问题，因为确保自主生成代码的质量和安全性至关重要。低质量的代码会导致系统故障、安全漏洞和其他重大问题。安全风险是另一个主要挑战，因为允许人工智能代理执行自行生成的代码，会使恶意行为者有可能利用此功能注入有害代码，从而导致数据泄露、未经授权的访问或系统损坏。实施强有力的安全措施和监督对于降低这些风险至关重要。

However, real-time code generation also presents several challenges and risks. Quality control is a major concern, as ensuring the quality and security of autonomously generated code is critical. Poor-quality code can lead to system failures, security breaches, and other significant issues. Security risks are another major challenge, as allowing AI agents to execute self-generated code introduces the potential for malicious actors to exploit this capability to inject harmful code, leading to data breaches, unauthorized access, or system damage. Implementing robust security measures and oversight is essential to mitigate these risks.

一个不太明显但却至关重要的缺点是可重复性。当你的代理每次都从头开始重新创建工具时，就会失去可预测性——一次调用成功并不能保证下一次调用也成功。性能可能会剧烈波动，提示信息或模型更新中的细微变化都可能导致完全不同的代码路径。这种不稳定性会使调试、测试和合规性变得复杂，难以保证你的代理始终按预期运行。

A less obvious but critical drawback is repeatability. When your agent recreates tools from scratch each time, you lose predictability—success for one invocation doesn’t guarantee success for the next. Performance can fluctuate wildly, and subtle changes in prompts or model updates can lead to entirely different code paths. This instability complicates debugging, testing, and compliance, making it hard to certify that your agent will always behave as expected.

资源消耗也是一个至关重要的考虑因素，因为实时代码的生成和执行可能非常消耗资源，需要大量的计算能力和记忆，尤其是在编写和执行简单或低效的解决方案时。对系统性能的多个方面设置限制措施有助于缓解资源消耗过高的问题。这些风险。

Resource consumption is also a critical consideration, as real-time code generation and execution can be resource-intensive, requiring substantial computational power and memory, especially when naive or inefficient solutions are drafted and executed. Placing guardrails on multiple aspects of system performance can help to mitigate these risks.

反射剂

Reflex Agents

反射剂实现从输入到动作的直接映射，无需任何内部推理过程。简单的反射代理遵循“如果条件，则执行”的规则，一旦检测到预定义的触发条件，便立即调用相应的工具。由于它们绕过了中间的思考步骤，反射代理能够以最小的开销提供响应。低延迟和可预测的性能使其非常适合基于关键字的路由、单步数据查找或基本自动化（例如，“如果 X，则调用工具 Y”）等用例。然而，其有限的表达能力意味着它们无法处理需要多步骤推理或超出直接输入上下文的任务。

Reflex agents implement a direct mapping from input to action without any internal reasoning trace. Simple reflex agents follow “if-condition, then-action” rules, calling the appropriate tool immediately upon detecting predefined triggers. Because they bypass intermediate thought steps, reflex agents deliver responses with minimal latency and predictable performance, making them well suited for use cases like keyword-based routing, single-step data lookups, or basic automations (e.g., “If X, call tool Y”). However, their limited expressiveness means they cannot handle tasks requiring multistep reasoning or context beyond the immediate input.

ReAct 代理

ReAct Agents

ReAct 试剂将推理和行动交错置于迭代循环中：模型生成一个想法，选择并调用一个工具，观察结果，并根据需要重复此过程。这种模式使智能体能够将复杂任务分解为易于管理的步骤，并根据中间观察结果更新其计划：

ReAct agents interleave Reasoning and Action in an iterative loop: the model generates a thought, selects and invokes a tool, observes the result, and repeats as needed. This pattern enables the agent to break complex tasks into manageable steps, updating its plan based on intermediate observations:

• ZERO_SHOT_REACT_DESCRIPTION（LangChain）在一个提示符中呈现工具和指令，依靠 LLM 的内在推理能力来选择和调用工具，而无需示例跟踪。

• ZERO_SHOT_REACT_DESCRIPTION (LangChain) presents tools and instructions in a single prompt, relying on the LLM’s innate reasoning to select and call tools without example traces.

• CHAT_ZERO_SHOT_REACT_DESCRIPTION通过整合对话历史记录，该功能得以扩展，使智能体能够在决定下一步行动时使用过去的交流。

• CHAT_ZERO_SHOT_REACT_DESCRIPTION extends this by incorporating conversational history, enabling the agent to use past exchanges when deciding on its next action.

ReAct 代理在探索性场景（例如动态数据分析、多源聚合或故障排除）中表现出色，在这些场景中，其实时调整的能力远​​胜于额外的延迟和计算开销。其循环结构也提供了透明性（“思路链”），有助于调试和审计，但同时也可能增加 API 成本和响应时间。

ReAct agents excel in exploratory scenarios—dynamic data analysis, multisource aggregation, or troubleshooting—where the ability to adapt midstream outweighs the additional latency and computational overhead. Their looped structure also provides transparency (“chain of thought”) that aids debugging and auditability, though it can increase API costs and response times.

规划执行代理人

Planner-Executor Agents

计划执行者智能体将任务分为两个截然不同的阶段：规划阶段，模型在此阶段生成多步骤计划；以及执行阶段，每个计划步骤通过工具调用来执行。这种清晰的划分使得规划器能够专注于长远推理，而执行器仅调用必要的工具，从而减少冗余的LLM调用。由于计划是显式的，调试和监控变得非常简单——您可以检查生成的计划，跟踪失败的步骤，并在需要时重新规划。这种方法具有多项优势：

Planner-executor agents split a task into two distinct phases: planning, where the model generates a multistep plan; and execution, where each planned step is carried out via tool calls. This clear separation lets the planner focus on long-horizon reasoning while executors invoke only the necessary tools, reducing redundant LLM calls. Because the plan is explicit, debugging and monitoring become straightforward—you can inspect the generated plan, track which step failed, and replan if needed. This approach has multiple advantages:

清晰的分解

Clear decomposition

复杂的任务可以分解成易于管理的子任务。

Complex tasks break down into manageable subtasks.

可调试性

Debuggability

明确的计划能够揭示错误发生的位置和原因。

Explicit plans reveal where and why errors occur.

成本效益

Cost efficiency

较小的模型或较少的 LLM 调用负责执行，而将大型模型保留用于规划。

Smaller models or fewer LLM calls handle execution, reserving large models for planning.

查询分解代理

Query-Decomposition Agents

查询分解代理解决复杂问题的方法是将其迭代地分解成子问题，针对每个子问题调用搜索或其他工具，然后综合得出最终答案。这种模式——通常被称为“自问自答式搜索”——遵循以下模型：“我需要什么后续问题？”→ 调用搜索 → “下一个问题是什么？”→ … → “最终答案是什么？”

Query-decomposition agents tackle a complex question by iteratively breaking it into subquestions, invoking search or other tools for each, and then synthesizing a final answer. This pattern—often called “self-ask with search”—prompts the model: “What follow-up question do I need?” → call search → “What’s the next question?” → … → “What’s the final answer?”

• 例子：SELF_ASK_WITH_SEARCH

• Example: SELF_ASK_WITH_SEARCH

• 问：“X 和 Y，谁活得更久？”

• Ask: “Who lived longer, X or Y?”

• 自问：“X 的寿命是多久？” → 搜索工具

• Self-ask: “What’s X’s lifespan?” → search tool

• 自问：“Y 的寿命有多长？” → 搜索工具

• Self-ask: “What’s Y’s lifespan?” → search tool

• 综合分析：“X活了85岁，Y活了90岁，所以Y活得更久。”

• Synthesize: “X lived 85 years, Y lived 90 years, so Y lived longer”

当需要外部知识检索时，这种方法非常有效，它能确保在撰写最终答案之前，每个事实都基于工具的输出。

This approach excels when external knowledge retrieval is needed, ensuring each fact is grounded in tool output before composing the final response.

反射代理

Reflection Agents

反射元推理智能体扩展了ReAct范式​​，它不仅将思考和行动交织在一起，还会回顾过去的步骤，以便在继续前进之前识别并纠正错误。在这种方法中——例如最近提出的ReflAct框架——智能体不断地将推理建立在目标状态反思之上，将当前状态与预期结果进行比较，并在出现偏差时调整计划。反思提示鼓励模型批判自身的思维链，纠正逻辑错误，并强化成功的策略，从而有效地模拟人类在解决复杂问题时的自我评估。

Reflection and metareasoning agents extend the ReAct paradigm by not only interleaving thought and action but also reviewing past steps to identify and correct mistakes before proceeding. In this approach—exemplified by the recently proposed ReflAct framework—the agent continuously grounds its reasoning in goal-state reflections, measuring its current state against the intended outcome and adjusting its plan when misalignments arise. Reflection prompts encourage the model to critique its own chain of thought, correct logical errors, and reinforce successful strategies, effectively simulating human-style self-assessment during complex problem-solving.

这种模式在高风险工作流程中尤为突出，因为早期错误可能会引发代价高昂的故障，例如金融交易编排、医疗诊断支持或重大事件响应。通过将每个操作与反射步骤相结合，代理可以检测到工具输出何时偏离预期，并在执行不可逆操作之前重新规划或回滚。虽然增加的元推理开销确实会带来额外的延迟和计算资源，但对于那些正确性和可靠性比速度更重要的任务而言，反射代理提供了一道强大的屏障，防止错误传播，并有助于维护系统稳定运行。与总体目标保持一致。

This pattern shines in high-stakes workflows where early errors can cascade into costly failures—such as financial transaction orchestration, medical diagnosis support, or critical incident response. By pairing each action with a reflection step, agents detect when tool outputs deviate from expectations and can replan or roll back before committing to irreversible operations. The added metareasoning overhead does incur extra latency and compute, but for tasks where correctness and reliability outweigh speed, reflection agents offer a powerful guardrail against error propagation and help maintain alignment with overarching goals.

深度研究代理

Deep Research Agents

深入研究深度研究专家擅长处理开放式、高度复杂的调查，这类调查需要广泛的外部知识收集、假设检验和综合分析——例如文献综述、科学发现或战略市场分析。他们结合多种模式：规划执行阶段，用于绘制研究工作流程图；查询分解阶段，用于将大问题分解为针对性搜索；以及迭代更新循环，用于根据新发现不断完善假设。在一个典型的周期中，深度研究专家会：

Deep research agents specialize in tackling open-ended, highly complex investigations that require extensive external knowledge gathering, hypothesis testing, and synthesis—think literature reviews, scientific discovery, or strategic market analysis. They combine multiple patterns: a planner-executor phase to chart research workflows; query-decomposition to break down big questions into targeted searches; and ReAct loops to iteratively refine hypotheses based on new findings. In a typical cycle, a deep research agent will:

1. 制定总体研究计划（例如，确定关键子主题或数据来源）。

2. Plan the overall research agenda (e.g., identify key subtopics or data sources).

3. 将每个子主题分解为具体查询（通过SELF_ASK或类似方式）。

4. Decompose each subtopic into concrete queries (via SELF_ASK or similar).

5. 调用各种工具——从学术搜索 API 到特定领域的数据库——并思考每个结果的相关性和可靠性。

6. Invoke tools—from academic search APIs to domain-specific databases—and reflect on the relevance and reliability of each result.

7. 将各种见解综合成一份不断完善的报告或一系列建议，并在每个步骤中使用 LLM 驱动的总结和批判。

8. Synthesize the insights into an evolving report or set of recommendations, using LLM-driven summarization and critique at each step.

优势

Strengths

能力

Capability

它可以处理高度复杂、多阶段的调查，这些调查依赖于专门的数据库和跨学科资源。

It can handle high-complexity, multistage investigations that lean on specialized databases and cross-disciplinary sources.

自适应

Adaptive

随着新证据的出现，研究方向会进行调整。

Research direction is adjusted as new evidence emerges.

透明的

Transparent

明确的计划和分解步骤使方法论的审核更加容易。

Explicit plans and decomposition steps make it easier to audit methodology.

弱点

Weaknesses

高昂的成本

High cost

大量使用基础模型和多次 API 调用会增加计算和代币费用。

Extensive foundation model use and multiple API calls inflate compute and token expenses.

延迟

Latency

规划、分解和反思的每一层都会增加延误。

Each layer of planning, decomposition, and reflection adds delay.

脆弱性

Fragility

它依赖于外部数据源的质量和可用性，需要谨慎的错误处理和备用策略。

It is reliant on quality and availability of external data sources and needs careful error handling and fallback strategies.

最佳应用场景是篇幅较长、专家级的任务——学术文献综述、技术尽职调查、竞争情报——这些任务需要深度和严谨性。速度胜过一切。

The best use cases are long-form, expert-level tasks—academic literature surveys, technical due diligence, competitive intelligence—where depth and rigor trump speed.

表 5-1概述了当今最常见的智能体原型——每种原型在速度、灵活性和复杂性方面各有优劣。然而，这种格局正在不断演变。以惊人的速度发展。新的混合模式、元推理框架和规划策略层出不穷，智能体类型的分类也只会变得更加细致。请将此列表视为一个起点，而非最终的分类体系：随着该领域的进步，你会看到基于这些基础构建的全新方法，因此请保持好奇心，经常进行实验，并随时准备随着研究和工具的不断成熟而调整你的编排策略。

Table 5-1 offers a snapshot of today’s most common agent archetypes—each with its own trade-offs in speed, flexibility, and complexity. However, this landscape is evolving at breakneck speed. New hybrid patterns, metareasoning frameworks, and planning strategies are emerging all the time, and the classification of agent types will only grow more nuanced. Consider this list a starting point rather than a definitive taxonomy: as the field advances, you’ll see fresh approaches built on these foundations, so stay curious, experiment often, and be ready to adapt your orchestration strategies as the research and tooling continue to mature.

表 5-1.常见代理人原型

代理类型	力量	弱点	最佳用例
反射 Reflex	毫秒级响应 Millisecond responses	没有多步骤推理 No multistep reasoning	关键词路由，简单查找 Keyword routing, simple lookups
反应 ReAct	灵活、即时的适应 Flexible, on-the-fly adaptation	更高的延迟和成本 Higher latency and cost	探索性工作流程、故障排除 Exploratory workflows, troubleshooting
计划-执行 Plan-execute	清晰的任务分解 Clear task breakdown	规划开销 Planning overhead	复杂的多步骤过程 Complex, multistep processes
查询分解 Query-decomposition	地面回收精度 Grounded retrieval accuracy	多次工具调用 Multiple tool calls	研究，基于事实的问答 Research, fact-based Q&A
反射 Reflection	早期错误检测 Early error detection	增加计算和延迟 Added compute and latency	高风险、安全攸关的任务 High-stakes, safety-critical tasks
深入研究 Deep research	多阶段、适应性调查的管理 Management of multistage, adaptive investigations	计算成本高，延迟极高 High compute costs and very high latency	长篇文献综述 Long-form literature reviews

标准工具选择

Standard Tool Selection

最简单的方法是标准工具选择。在这种情况下，工具、其定义和描述被提供给基础模型，并要求模型为给定的上下文选择最合适的工具。然后，将基础模型的输出与工具集进行比较，并选择最接近的工具。这种方法易于实现，无需额外的训练、嵌入或工具集层次结构。其主要缺点是延迟问题在于，它需要再次调用基础模型，这可能会使整体响应时间增加几秒。此外，它还可以受益于上下文学习，即通过提供少量样本来提高问题的预测精度，而无需训练或微调模型。

The simplest approach is standard tool selection. In this case, the tool, its definition, and its description are provided to a foundation model, and the model is asked to select the most appropriate tool for the given context. The output from the foundation model is then compared with the toolset, and the closest one is chosen. This approach is easy to implement, and requires no additional training, embedding, or a toolset hierarchy to use. The main drawback is latency, as it requires another foundation model call, which can add seconds to the overall response time. It can also benefit from in-context learning, where few-shot examples can be provided to boost predictive accuracy for your problem without the challenge of training or fine-tuning a model.

有效的工具选择往往取决于你如何描述每项功能。首先，给每项工具赋予特定的功能。使用简洁明了的描述性名称（例如，calculate_sum而不是使用process_numbers“返回两个数字之和”），并在名称后添加一句概括性的句子，突出其独特用途（例如，“返回两个数字之和”）。在描述中包含一个示例调用——展示典型的输入和输出——以便模型能够基于具体概念而非抽象语言来理解工具。最后，通过指定类型和范围来强制执行输入约束（例如，“x 和 y 必须是 0 到 1000 之间的整数”），这可以减少歧义匹配，并帮助基础模型排除不相关的工具。通过使用具有代表性的提示进行迭代测试，并不断完善每个描述的清晰度和具体性，您将在无需任何额外训练或基础设施的情况下显著提高选择准确率。这听起来很简单，但随着您向代理注册的工具数量不断增加，工具描述中的重叠经常会成为一个问题，并导致工具选择错误。这里我们定义了另一个能够计算数学表达式和评估公式的工具，而基础模型通常不擅长处理这类任务：

Effective tool selection often comes down to how you describe each capability. Start by giving every tool a concise, descriptive name (e.g., calculate_sum instead of process_numbers) and follow it with a one-sentence summary that highlights its unique purpose (e.g., “Returns the sum of two numbers”). Include an example invocation in the description—showing typical inputs and outputs—to ground the model’s understanding in concrete terms rather than abstract language. Finally, enforce input constraints by specifying types and ranges (e.g., “x and y must be integers between 0 and 1,000”), which reduces ambiguous matches and helps the foundation model rule out irrelevant tools. By iteratively testing with representative prompts and refining each description for clarity and specificity, you’ll see significant gains in selection accuracy without any extra training or infrastructure. This sounds simple enough, but as the number of tools you register with your agent grows, overlap in the tool descriptions frequently becomes a problem and a source of mistakes in tool selection. Here we define another tool that is capable of computing mathematical expressions and evaluating formulas, something foundation models tend to not be good at:

from langchain_core.tools import tool 
import requests

@tool 
def query_wolfram_alpha(expression: str) -> str: 
    """
    Query Wolfram Alpha to compute expressions or retrieve information. 
    Args: expression (str): The mathematical expression or query to evaluate. 
    Returns: str: The result of the computation or the retrieved information. 
        """

    api_url = f'''https://api.wolframalpha.com/v1/result?
        i={requests.utils.quote(expression)}&
        appid=YOUR_WOLFRAM_ALPHA_APP_ID'''  

    try:
        response = requests.get(api_url)
        if response.status_code == 200: 
            return response.text 
        else: raise ValueError(f"Wolfram Alpha API Error: 
            {response.status_code} - {response.text}") 
    except requests.exceptions.RequestException as e: 
        raise ValueError(f"Failed to query Wolfram Alpha: {e}")


@tool 
def trigger_zapier_webhook(zap_id: str, payload: dict) -> str: 
    """ Trigger a Zapier webhook to execute a predefined Zap. 
    Args: 
    zap_id (str): The unique identifier for the Zap to be triggered. 
    payload (dict): The data to send to the Zapier webhook. 
    Returns: 
    str: Confirmation message upon successful triggering of the Zap. 
    Raises: ValueError: If the API request fails or returns an error. 
    """ 

    zapier_webhook_url = f"https://hooks.zapier.com/hooks/catch/{zap_id}/" 
    try: 
        response = requests.post(zapier_webhook_url, json=payload) 
        if response.status_code == 200: 
            return f"Zapier webhook '{zap_id}' successfully triggered." 

        else: 
        raise ValueError(f'''Zapier API Error: {response.status_code} - 
                         {response.text}''') 
    except requests.exceptions.RequestException as e: 
        raise ValueError(f"Failed to trigger Zapier webhook '{zap_id}': {e}") 

以下是另一个您可能需要向代理注册的工具示例，以便在任务完成或需要关注时通知特定渠道，从而实现人机协作模式：

Here’s another example of a tool you might want to register with your agent to notify a particular channel when your task is completed or needs attention for a human-in-the-loop pattern:

@tool 
def send_slack_message(channel: str, message: str) -> str: 
    """ Send a message to a specified Slack channel. 
    Args: 
    channel (str): The Slack channel ID or name where the message will be sent. 
    message (str): The content of the message to send. 
    Returns: 
    str: Confirmation message upon successful sending of the Slack message. 
    Raises: ValueError: If the API request fails or returns an error. 
    """ 

    api_url = "https://slack.com/api/chat.postMessage" 
        headers = { "Authorization": "Bearer YOUR_SLACK_BOT_TOKEN",
                    "Content-Type": "application/json" } 
    payload = { "channel": channel, "text": message } 
    try: 
        response = requests.post(api_url, headers=headers, json=payload) 
        response_data = response.json() 
        if response.status_code == 200 and response_data.get("ok"): 
            return f"Message successfully sent to Slack channel '{channel}'." 
        else: 
            error_msg = response_data.get("error", "Unknown error") 
            raise ValueError(f"Slack API Error: {error_msg}") 
        except requests.exceptions.RequestException as e: 
            raise ValueError(f'''Failed to send message to Slack channel 
                             "{channel}": {e}''')

现在我们已经定义了工具，接下来将它们绑定到模型客户端，并允许模型选择要调用哪些工具来最好地处理输入：

Now that we’ve defined our tools, we bind them to the model client and allow the model to pick which tools to invoke to best address the input:

# Initialize the LLM with GPT-4o and bind the tools
llm = ChatOpenAI(model_name="gpt-4o")
llm_with_tools = llm.bind_tools([get_stock_price, 
    send_slack_message, query_wolfram_alpha])

messages = [HumanMessage("What is the stock price of Apple?")]

ai_msg = llm_with_tools.invoke(messages)
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:
   tool_msg = get_stock_price.invoke(tool_call)

final_response = llm_with_tools.invoke(messages)
print(final_response.content)

总而言之，标准工具选择提供了一种快速、直观的方式，无需额外的基础设施或培训成本即可将工具集成到您的代理系统中。虽然它在小型工具集方面扩展性良好，但随着工具库的增长，精心设计的描述变得至关重要，以确保准确性并避免误选。通过将周全的描述与迭代提示测试相结合，您可以使用这种简单而有效的方法实现稳健的性能。强有力的方法。

In summary, standard tool selection offers a fast, intuitive way to integrate tools into your agent system without additional infrastructure or training overhead. While it scales well for small toolsets, careful description engineering becomes essential as your tool library grows to maintain accuracy and avoid misselection. By combining thoughtful descriptions with iterative prompt testing, you can achieve robust performance using this simple yet powerful approach.

语义工具选择

Semantic Tool Selection

另一种方法是语义工具选择，它使用语义该方法首先建立表示形式，对所有可用工具进行索引，然后通过语义搜索检索最相关的工具。这减少了可供选择的工具数量，并依靠基础模型从这个更小的集合中选择正确的工具和参数。预先，每个工具的定义和描述都使用仅编码器模型（例如 OpenAI 的 Ada 模型、Amazon 的 Titan 模型、Cohere 的 Embed 模型、ModernBERT 等）进行嵌入，该模型将工具名称和描述表示为一个数字向量。图 5-2展示了这一过程，图中显示了如何将每个工具嵌入到向量表示中，以便基于与任务查询的语义相似性进行高效检索。

Another approach, semantic tool selection, uses semantic representations to index all of the available tools and semantic search to retrieve the most relevant tools. This reduces the number of tools to choose from and then relies on the foundation model to choose the correct tool and parameters from this much smaller set. Ahead of time, each tool definition and description is embedded using an encoder-only model—such as OpenAI’s Ada model, Amazon’s Titan model, Cohere’s Embed model, ModernBERT, or others—which represents the tool name and description as a vector of numbers. This process is illustrated in Figure 5-2, which shows how each tool is embedded into a vector representation for efficient retrieval based on semantic similarity to the task query.

图 5-2.基于语义的工具嵌入，用于检索式选择。每个工具或技能都使用嵌入模型编码成密集向量表示。这些向量随后被存储起来，以便进行高效的语义搜索，从而使系统能够根据任务查询检索到最相关的工具。

这些工具随后被索引到一个轻量级向量数据库中。运行时，系统使用相同的嵌入模型对当前上下文进行嵌入，并在数据库中执行搜索，选择并检索最相关的工具。这些工具随后被传递给基础模型，基础模型可以选择调用某个工具并设置相应的参数。工具被调用后，其响应被用于生成最终的用户响应。图 5-3展示了这一过程，图中显示了系统如何检索相关工具，以及如何使用基础模型选择并调用合适的工具及其参数来生成最终响应。

These tools are then indexed in a lightweight vector database. At runtime, the current context is embedded using the same embedding model, a search is performed on the database, and the top tools are selected and retrieved. These tools are then passed to the foundation model, which can then choose to invoke a tool and choose the parameters. The tool is then invoked, and the response is used to compose the response for the user. This process is illustrated in Figure 5-3, which shows how the system retrieves relevant tools and uses the foundation model to select and invoke the appropriate tool with its parameters to generate the final response.

图 5-3.语义工具检索和调用工作流程。在运行时，用户查询被嵌入并用于从向量数据库中检索最相关的工具。然后，基础模型选择合适的工具并确定其参数，调用该工具，并将工具的输出整合以生成最终的用户响应。

这是最常见的模式，推荐用于大多数用例。它通常比标准工具选择速度更快、性能更高，并且具有良好的可扩展性。首先，通过嵌入工具描述来设置工具数据库：

This is the most common pattern and is recommended for most use cases. It’s typically faster than standard tool selection, performant, and reasonably scalable. First, the tool database is set up by embedding the tool descriptions:

import os
import requests
import logging
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_core.messages import HumanMessage, AIMessage, ToolMessage
from langchain.vectorstores import FAISS
import faiss
import numpy as np

# Initialize OpenAI embeddings
embeddings = OpenAIEmbeddings(openai_api_key=OPENAI_API_KEY)

# Tool descriptions
tool_descriptions = {
       "query_wolfram_alpha": '''Use Wolfram Alpha to compute mathematical  
                                 expressions or retrieve information.''',
       "trigger_zapier_webhook": '''Trigger a Zapier webhook to execute  
                                    predefined automated workflows.''',
       "send_slack_message": '''Send messages to specific Slack channels to 
                                communicate with team members.'''
}

# Create embeddings for each tool description
tool_embeddings = []
tool_names = []

for tool_name, description in tool_descriptions.items():
   embedding = embeddings.embed_text(description)
   tool_embeddings.append(embedding)
   tool_names.append(tool_name)

# Initialize FAISS vector store
dimension = len(tool_embeddings[0])  
index = faiss.IndexFlatL2(dimension)

# Normalize embeddings for cosine similarity
faiss.normalize_L2(np.array(tool_embeddings).astype('float32'))

# Convert list to FAISS-compatible format
tool_embeddings_np = np.array(tool_embeddings).astype('float32')
index.add(tool_embeddings_np)

# Map index to tool functions
index_to_tool = {
   0: query_wolfram_alpha,
   1: trigger_zapier_webhook,
   2: send_slack_message
}

工具目录的这些嵌入向量只需计算一次，即可快速检索。要选择工具，您只需使用相同的嵌入模型嵌入查询，执行快速数据库查找，选择参数，然后调用即可。我们的工具：

Those embeddings for your tool catalog only need to be computed once, and now they’re ready to be quickly retrieved. To choose your tool, you embed your query using the same embedding model, perform a quick database lookup, choose the parameters, and invoke our tool:

def select_tool(query: str, top_k: int = 1) -> list:
   """
   Select the most relevant tool(s) based on the user's query using 
   vector-based retrieval.
  
   Args:
       query (str): The user's input query.
       top_k (int): Number of top tools to retrieve.
      
   Returns:
       list: List of selected tool functions.
   """
   query_embedding = embeddings.embed_text(query).astype('float32')
   faiss.normalize_L2(query_embedding.reshape(1, -1))
   D, I = index.search(query_embedding.reshape(1, -1), top_k)
   selected_tools = [index_to_tool[idx] for idx in I[0] if idx in index_to_tool]
   return selected_tools

def determine_parameters(query: str, tool_name: str) -> dict:
   """
   Use the LLM to analyze the query and determine the parameters for the tool 
   to be invoked.
  
   Args:
       query (str): The user's input query.
       tool_name (str): The selected tool name.
      
   Returns:
       dict: Parameters for the tool.
   """
   messages = [
       HumanMessage(content=f'''Based on the user's query: '{query}', what 
           parameters should be used for the tool '{tool_name}'?''')
   ]
  
   # Call the LLM to extract parameters
   response = llm(messages)
  
   # Example logic to parse response from LLM
   parameters = {}
   if tool_name == "query_wolfram_alpha":
       parameters["expression"] = response['expression']  
       # Extract mathematical expression
   elif tool_name == "trigger_zapier_webhook":
       parameters["zap_id"] = response.get('zap_id', "123456")  
       parameters["payload"] = response.get('payload', {"data": query})
   elif tool_name == "send_slack_message":
       parameters["channel"] = response.get('channel', "#general")
       parameters["message"] = response.get('message', query)
  
   return parameters

# Example user query
user_query = "Solve this equation: 2x + 3 = 7"

# Select the top tool
selected_tools = select_tool(user_query, top_k=1)
tool_name = selected_tools[0] if selected_tools else None

if tool_name:
   # Use LLM to determine the parameters based on the query and the selected tool
   args = determine_parameters(user_query, tool_name)

   # Invoke the selected tool
   try:
       # Assuming each tool has an `invoke` method to execute it
       tool_result = globals()[tool_name].invoke(args)
       print(f"Tool '{tool_name}' Result: {tool_result}")
   except ValueError as e:
       print(f"Error invoking tool '{tool_name}': {e}")
else:
   print("No tool was selected.")

分层工具选择

Hierarchical Tool Selection

如果你的情况虽然涉及大量工具，但您可能需要考虑分层工具选择。如果许多工具语义相似，并且您希望以更高的延迟和复杂性为代价来提高工具选择的准确性，那么分层工具选择就显得尤为重要。在这种模式下，您可以将工具组织成组，并为每个组提供描述。您的工具选择（无论是生成式还是语义式）首先选择一个组，然后仅在该组内的工具中执行二次搜索。图 5-4可视化了这一两阶段过程，展示了查询如何首先被路由到相应的工具组，然后被细化到该组内的单个工具。

If your scenario involves a large number of tools, however, you might need to consider hierarchical tool selection. This is especially true if many of those tools are semantically similar and you are looking to improve tool selection accuracy at the price of higher latency and complexity. In this pattern, you organize your tools into groups and provide a description for each group. Your tool selection (either generative or semantic) first selects a group and then performs a secondary search only among the tools in that group. Figure 5-4 visualizes this two-stage process, showing how a query is first routed to the appropriate tool group and then refined to a single tool within that group.

图 5-4.分层工具选择工作流程。代理首先选择与查询最相关的工具组，然后缩小搜索范围，选择该组内的单个工具——在本例中，将数学问题路由到该工具组，并最终调用该工具query_wolfram_alpha。

虽然这种方法速度较慢且并行化成本较高，但它将刀具选择任务的复杂性简化为两个较小的部分，并且通常能提高整体刀具选择的准确率。创建和维护这些刀具组需要时间和精力，因此除非您有大量刀具，否则不建议采用这种方法。

While this is slower and would be expensive to parallelize, it reduces the complexity of the tool selection task into two smaller chunks, and frequently results in higher overall tool selection accuracy. Crafting and maintaining these tool groups takes time and effort, so this is not recommended unless you have a large number of tools:

import os
import requests
import logging
import numpy as np
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, AIMessage, ToolMessage

# Initialize the LLM
llm = ChatOpenAI(model_name="gpt-4", temperature=0)

# Define tool groups with descriptions
tool_groups = {
    "Computation": {
        "description": '''Tools related to mathematical computations and 
                          data analysis.''',
        "tools": []
    },
    "Automation": {
        "description": '''Tools that automate workflows and integrate 
                          different services.''',
        "tools": []
    },
    "Communication": {
        "description": "Tools that facilitate communication and messaging.",
        "tools": []
    }
}

# Define Tools
@tool
def query_wolfram_alpha(expression: str) -> str:
    api_url = f'''https://api.wolframalpha.com/v1/result?i=
    {requests.utils.quote(expression)}&appid={WOLFRAM_ALPHA_APP_ID}'''
    try:
        response = requests.get(api_url)
        if response.status_code == 200:
            return response.text
        else:
            raise ValueError(f'''Wolfram Alpha API Error: {response.status_code}
                            - {response.text}''')
    except requests.exceptions.RequestException as e:
        raise ValueError(f"Failed to query Wolfram Alpha: {e}")

@tool
def trigger_zapier_webhook(zap_id: str, payload: dict) -> str:
    zapier_webhook_url = f"https://hooks.zapier.com/hooks/catch/{zap_id}/"
    try:
        response = requests.post(zapier_webhook_url, json=payload)
        if response.status_code == 200:
            return f"Zapier webhook '{zap_id}' successfully triggered."
        else:
            raise ValueError(f'''Zapier API Error: {response.status_code} -
                                 {response.text}''')
    except requests.exceptions.RequestException as e:
        raise ValueError(f"Failed to trigger Zapier webhook '{zap_id}': {e}")

@tool
def send_slack_message(channel: str, message: str) -> str:
    api_url = "https://slack.com/api/chat.postMessage"
    headers = {
        "Authorization": f"Bearer {SLACK_BOT_TOKEN}",
        "Content-Type": "application/json"
    }
    payload = {
        "channel": channel,
        "text": message
    }
    try:
        response = requests.post(api_url, headers=headers, json=payload)
        response_data = response.json()
        if response.status_code == 200 and response_data.get("ok"):
            return f"Message successfully sent to Slack channel '{channel}'."
        else:
            error_msg = response_data.get("error", "Unknown error")
            raise ValueError(f"Slack API Error: {error_msg}")
    except requests.exceptions.RequestException as e:
        raise ValueError(f'''Failed to send message to Slack channel 
                        '{channel}': {e}''')

# Assign tools to their respective groups
tool_groups["Computation"]["tools"].append(query_wolfram_alpha)
tool_groups["Automation"]["tools"].append(trigger_zapier_webhook)
tool_groups["Communication"]["tools"].append(send_slack_message)

# -------------------------------
# LLM-Based Hierarchical Tool Selection
# -------------------------------
def select_group_llm(query: str) -> str:
    """
    Use the LLM to determine the most appropriate tool group based on the  
    user's query.
    
    Args:
        query (str): The user's input query.
        
    Returns:
        str: The name of the selected group.
    """
    prompt = f'''Select the most appropriate tool group for the following query: 
        '{query}'.\nOptions are: Computation, Automation, Communication.'''
    response = llm([HumanMessage(content=prompt)])
    return response.content.strip()

def select_tool_llm(query: str, group_name: str) -> str:
    """
    Use the LLM to determine the most appropriate tool within a group based  
    on the user's query.
    
    Args:
        query (str): The user's input query.
        group_name (str): The name of the selected tool group.
        
    Returns:
        str: The name of the selected tool function.
    """
    prompt = f'''Based on the query: '{query}', select the most appropriate 
                 tool from the group '{group_name}'.'''
    response = llm([HumanMessage(content=prompt)])
    return response.content.strip()

# Example user query
user_query = "Solve this equation: 2x + 3 = 7"

# Step 1: Select the most relevant tool group using LLM
selected_group_name = select_group_llm(user_query)
if not selected_group_name:
    print("No relevant tool group found for your query.")
else:
    logging.info(f"Selected Group: {selected_group_name}")
    print(f"Selected Tool Group: {selected_group_name}")

    # Step 2: Select the most relevant tool within the group using LLM
    selected_tool_name = select_tool_llm(user_query, selected_group_name)
    selected_tool = globals().get(selected_tool_name, None)
    
    if not selected_tool:
        print("No relevant tool found within the selected group.")
    else:
        logging.info(f"Selected Tool: {selected_tool.__name__}")
        print(f"Selected Tool: {selected_tool.__name__}")
        
        # Prepare arguments based on the tool
        args = {}
        if selected_tool == query_wolfram_alpha:
            # Assume the entire query is the expression
            args["expression"] = user_query
        elif selected_tool == trigger_zapier_webhook:
            # Use placeholders for demo
            args["zap_id"] = "123456"
            args["payload"] = {"message": user_query}
        elif selected_tool == send_slack_message:
            # Use placeholders for demo
            args["channel"] = "#general"
            args["message"] = user_query
        else:
            print("Selected tool is not recognized.")
        
        # Invoke the selected tool
        try:
            tool_result = selected_tool.invoke(args)
            print(f"Tool '{selected_tool.__name__}' Result: {tool_result}")
        except ValueError as e:
            print(f"Error: {e}")

单工具执行

Single Tool Execution

我们将开始对于只需要一种工具的任务，规划就显得尤为重要。在这种情况下，规划的核心在于选择最适合完成任务的工具。一旦选定工具，就必须根据工具定义对其进行正确的参数化。然后执行该工具，并将其输出作为输入，用于生成最终的用户响应，如图5-5所示。虽然这只是一个最基本的规划定义，但它是我们构建更复杂模式的基础。

We’ll begin with tasks that require precisely one tool. In this case, planning consists of choosing the one tool most appropriate to address the task. Once the tool is selected, it must be correctly parameterized based on the tool definition. The tool is then executed, and its output is used as an input when composing the final response for the user, which can be seen in Figure 5-5. While this is a minimal definition of a plan, it is the foundation from which we will build more complex patterns.

图 5-5.单个工具执行工作流程。用户查询被传递给模型（步骤 1），模型从工具集中选择合适的工具（步骤 2），接收工具输出（步骤 3），并生成最终的响应给用户（步骤 4）。

为了使这个例子更加具体，图 5-6显示了同一个单一工具执行工作流程，其中代理检索并返回纽约市的当前天气。

To make this example more concrete, Figure 5-6 shows this same single tool execution workflow where the agent retrieves and returns the current weather for New York City.

图 5-6.单个工具执行天气检索的示例。用户询问纽约市的天气，模型选择并参数化天气工具，以 JSON 有效负载的形式检索温度和天气状况，并利用这些信息为用户生成自然语言响应。

虽然这种单一工具执行模式很简单，但它构成了高级代理系统中更复杂的多步骤规划和工具编排策略的基础。下一节，我们将探讨如何在不增加延迟的情况下执行更多工具。

While this single tool execution pattern is simple, it forms the foundation upon which more complex multistep planning and tool orchestration strategies are built in advanced agent systems. In the next section, we’ll look at how we can execute more tools without sacrificing latency.

并行工具执行

Parallel Tool Execution

第一次增长复杂性的增加源于工具的并行性。在某些情况下，对输入执行多个操作可能是值得的。例如，假设您需要查找某个患者的记录。如果您的工具集包含多个访问多个数据源的工具，那么就需要执行多个操作才能从每个数据源检索数据。这会增加问题的复杂性，因为无法确定需要执行多少个工具。一种常见的方法是使用语义工具选择来检索可能执行的最大工具数量——例如，五个。接下来，使用这五个工具分别调用基础模型，并要求它选择解决问题所需的五个或更少的工具，从而筛选出完成任务所需的工具。类似地，可以重复调用基础模型，并传入已选择工具的上下文信息，直到它选择不再添加任何工具为止。一旦选定，这些工具将被独立地参数化并执行。所有工具执行完毕后，它们的结果将被传递给基础模型，以便为用户生成最终响应。图 5-7展示了这种模式。

The first increase in complexity comes with tool parallelism. In some cases, it might be worth taking multiple actions on the input. For example, imagine that you need to look up a record for a patient. If your toolset includes multiple tools that access multiple sources of data, then it will be necessary to execute multiple actions to retrieve data from each of the sources. This increases the complexity of the problem because it is unclear how many tools need to be executed. A common approach is to retrieve a maximum number of tools that might be executed—say, five—using semantic tool selection. Next, make a second call to a foundation model with each of these five tools, and ask it to select the five or fewer tools that are necessary to the problem, filtering down to the tools necessary for the task. Similarly, the foundation model can be called repeatedly with the additional context of which tools have already been selected until it chooses to add no more tools. Once selected, these tools are independently parameterized and executed. After all tools have been completed, their results are passed to the foundation model to draft a final response for the user. Figure 5-7 illustrates this pattern.

图 5-7.并行工具执行模式。在本例中，用户询问如何处理客户工单。流程编排会选择多个工具并行运行，例如检索客户详细信息、订单历史记录、服务日志、类似工单和相关支持策略，然后整合它们的输出以生成最终响应。

这种并行工具执行模式使智能体能够在一步之内高效地从多个来源收集全面信息。通过在生成响应之前整合这些结果，智能体可以提供更丰富、更详尽的输出，同时最大限度地降低整体延迟。

This pattern of parallel tool execution enables agents to efficiently gather comprehensive information from multiple sources in a single step. By integrating these results before composing a response, the agent can provide richer, more informed outputs while minimizing overall latency.

链条

Chains

下一次增长复杂性让我们想到链。链指的是一系列依次执行的动作，每个动作都依赖于前一个动作的成功完成。规划链包括确定为实现特定目标应执行的动作顺序，同时确保每个动作都能无缝衔接到下一个动作。链常见于涉及分步流程或线性工作流程的任务中。

The next increase in complexity brings us to chains. Chains refer to sequences of actions that are executed one after another, with each action depending on the successful completion of the previous one. Planning chains involves determining the order in which actions should be performed to achieve a specific goal while ensuring that each action leads to the next without interruption. Chains are common in tasks that involve step-by-step processes or linear workflows.

幸运的是，LangChain 提供了一种声明式语法，即 LangChain 表达式语言 (LCEL)。LCEL 允许通过组合现有的 Runnable 来构建链，而不是手动连接Chain对象。在底层，LCEL 将每个链都视为实现了相同接口的 Runnable，因此您可以invoke()像batch()操作stream()其他 Runnable 一样操作任何 LCEL 链：

Fortunately, LangChain offers a declarative syntax, the LangChain Expression Language (LCEL), to build chains by composing existing Runnables rather than manually wiring up Chain objects. Under the hood, LCEL treats every chain as a Runnable implementing the same interface, so you can invoke(), batch(), or stream() any LCEL chain just like any other Runnable:

from langchain_core.runnables import RunnableLambda
from langchain.chat_models import ChatOpenAI
from langchain_core.prompts import PromptTemplate
# Wrap a function or model call as a Runnable
llm = RunnableLambda.from_callable(ChatOpenAI(model_name="gpt-4", 
                                  temperature=0).generate)
prompt = RunnableLambda.from_callable(lambda text: 
    PromptTemplate.from_template(text).format_prompt({"input": text}
                                      ).to_messages())
# Traditional chain equivalent:
# chain = LLMChain(prompt=prompt, llm=llm)
# LCEL chain using pipes:
chain = prompt | llm
# Invoke the chain
result = chain.invoke("What is the capital of France?")

通过切换到 LCEL，您可以减少样板代码，获得高级执行功能，并保持链的简洁性和可维护性。图 5-8展示了许多 LCEL 工作流所基于的通用代理链模式。

By switching to LCEL, you reduce boilerplate, gain advanced execution features, and keep your chains concise and maintainable. Figure 5-8 illustrates the general agentic chain pattern that underlies many LCEL workflows.

图 5-8.智能体链执行模式。用户提示被传递给模型，模型进行推理并调用工具与环境交互。生成的观测结果被循环返回到模型中进行进一步推理，直到任务完成。

规划链式任务需要仔细考虑各步骤之间的依赖关系，旨在协调一系列连贯的活动，最终达成预期结果。强烈建议为工具链设置最大长度，因为错误会沿着链式任务不断累积。只要任务预计不会衍生出多个分支子任务，链式任务就能在规划多个具有依赖关系的工具与保持任务复杂性之间取得良好的平衡。相对较低。

The planning of chains requires careful consideration of the dependencies between actions, aiming to orchestrate a coherent flow of activity toward the desired outcome. It is highly recommended that a maximum length be set to the tool chains, as errors can compound down the length of the chain. As long as the task is not expected to fan out to multiple branching subtasks, chains provide an excellent trade-off between adding planning for multiple tools with dependencies and keeping the complexity relatively low.

图表

Graphs

为了支持对于具有多个决策点的场景，图拓扑结构比链式或树状结构更能清晰地模拟复杂的、非层级化的流程。与线性链或严格分支的树不同，图结构允许您定义条件边和合并边，从而使并行路径能够合并回共享节点。

For support scenarios with multiple decision points, a graph topology models complex, nonhierarchical flows far more expressively than chains or trees. Unlike linear chains or strictly branching trees, graph structures let you define both conditional edges and consolidation edges, so that parallel paths can merge back into shared nodes.

图中的每个节点代表一次离散的工具调用（或逻辑步骤），而边（包括连接线）则add_conditional_edges声明了代理程序可以在哪些特定条件下进行步骤转换。通过将来自多个分支的输出合并到单个下游节点（例如，连接线summarize_response），您可以将来自不同处理程序的发现拼接成统一的客户回复。

Each node in a graph represents a discrete tool invocation (or logical step), while edges—including add_conditional_edges—declare the exact conditions under which the agent may transition between steps. By consolidating outputs from multiple branches into a single downstream node (e.g., summarize_response), you can stitch together findings from separate handlers into a unified customer reply.

然而，完整的图执行通常会比链式调用产生更多的基础模型调用——此外延迟和成本——因此限制深度和分支因子至关重要。此外，循环、不可达节点或冲突的状态合并会引入新的错误类型，必须通过严格的验证和测试来管理。以下示例展示了如何在 中实现图。LangGraph：

However, full graph execution typically incurs significantly more foundation model calls than chains—adding latency and cost—so it’s crucial to cap depth and branching factor. In addition, cycles, unreachable nodes, or conflicting state merges introduce new classes of errors that must be managed through rigorous validation and testing. The following is an example for how to implement a graph in LangGraph:

from langgraph.graph import StateGraph, START, END
from langchain.chat_models import ChatOpenAI

# Initialize LLM
llm = ChatOpenAI(model_name="gpt-4", temperature=0)
# 1. Node definitions
def categorize_issue(state: dict) -> dict:
    prompt = (
        f"Classify this support request as 'billing' or 'technical'.\n\n"
        f"Message: {state['user_message']}"
    )
    generations = llm.generate([{"role":"user","content":prompt}]).generations
    kind = generations[0][0].text.strip().lower()
    return {**state, "issue_type": kind}
def handle_invoice(state: dict) -> dict:
    # Fetch invoice details...
    return {**state, "step_result": f"Invoice details for {state['user_id']}"}
def handle_refund(state: dict) -> dict:
    # Initiate refund workflow...
    return {**state, "step_result": "Refund process initiated"}
def handle_login(state: dict) -> dict:
    # Troubleshoot login...
    return {**state, "step_result": "Password reset link sent"}
def handle_performance(state: dict) -> dict:
    # Check performance metrics...
    return {**state, "step_result": "Performance metrics analyzed"}
def summarize_response(state: dict) -> dict:
    # Consolidate previous step_result into a user-facing message
    details = state.get("step_result", "")
    summary = llm.generate([{"role":"user","content":
        f"Write a concise customer reply based on: {details}"
    }]).generations[0][0].text.strip()
    return {**state, "response": summary}

下一部分将每个节点中的逻辑流程连接成一个实际的执行图。通过创建一个新的节点StateGraph，我们以 START → 为起点categorize_issue，确保每个请求首先经过分类步骤。然后，使用add_conditional_edges来编码核心业务规则：分类后，只有计费问题才会路由到发票/退款处理程序，只有技术问题才会路由到登录/性能处理程序。每个路由函数都会检查不断变化的状态并返回下一个节点的名称，映射确保运行时只启用有效的后续节点。这种方法使决策逻辑清晰明确，强制执行正确的工具调用顺序，并防止无效的转换——所有这些都在执行任何工具调用之前完成：

This next section wires up the logical flow in each node into an actual execution graph. By creating a new StateGraph, we establish the starting point with START → categorize_issue, which ensures every request first passes through the classification step. Then, using add_conditional_edges, you encode the core business rules: after categorization, only billing issues route into the invoice/refund handlers, and only technical issues route into the login/performance handlers. Each router function inspects the evolving state and returns the name of the next node, and the mapping ensures that only valid successors are enabled at runtime. This approach keeps the decision logic explicit, enforces the correct sequence of tool invocations, and prevents invalid transitions—all before we ever execute a single tool call:

# 2. Build the graph
graph = StateGraph()
# Start → categorize_issue
graph.add_edge(START, categorize_issue)
# categorize_issue → billing or technical
def top_router(state):
    return "billing" if state["issue_type"] == "billing" else "technical"
graph.add_conditional_edges(
    categorize_issue,
    top_router,
    mapping={"billing": handle_invoice, "technical": handle_login}
)
# Billing sub-branches: invoice vs. refund
def billing_router(state):
    msg = state["user_message"].lower()
    return "invoice" if "invoice" in msg else "refund"
graph.add_conditional_edges(
    handle_invoice,
    billing_router,
    mapping={"invoice": handle_invoice, "refund": handle_refund}
)
# Technical sub-branches: login vs. performance
def tech_router(state):
    msg = state["user_message"].lower()
    return "login" if "login" in msg else "performance"
graph.add_conditional_edges(
    handle_login,
    tech_router,
    mapping={"login": handle_login, "performance": handle_performance}
)

最后这部分连接添加了合并边，这样无论用户选择哪条子路径——无论是查询发票、退款、登录故障排除还是性能检查——其结果都会汇入同一个summarize_response节点。通过将每个处理节点（handle_refund、、和）连接到，可以确保所有不同的结果都被统一到一个连贯的客户回复中。最后，连接到可以干净利落地终止工作流，保证在图结束之前，所有执行路径都会收敛到一个完善的响应handle_performance。handle_invoicehandle_loginsummarize_responsesummarize_responseEND

This final wiring adds consolidation edges so that, no matter which subpath was taken—whether the user needed an invoice lookup, a refund, login troubleshooting, or performance checks—their result feeds into the single summarize_response node. By connecting each of the handler nodes (handle_refund, handle_performance, handle_invoice, and handle_login) into summarize_response, you ensure all divergent outcomes are unified into one coherent customer reply. Finally, linking summarize_response to END cleanly terminates the workflow, guaranteeing every execution path converges on a polished response before the graph finishes:

# Consolidation: both refund and performance (and invoice/login) lead here
graph.add_edge(handle_refund, summarize_response)
graph.add_edge(handle_performance, summarize_response)
# Also cover paths where invoice or login directly go to summary
graph.add_edge(handle_invoice, summarize_response)
graph.add_edge(handle_login, summarize_response)
# Final: summary → END
graph.add_edge(summarize_response, END)
# 3. Execute the graph
initial_state = {
    "user_message": "Hi, I need help with my invoice and possibly a refund.",
    "user_id": "U1234"
}
result = graph.run(initial_state, max_depth=5)
print(result["response"])

图表它为建模复杂的非线性工作流程提供了极致的灵活性——使您能够将多个工具的执行分支、合并和整合到一个统一的流程中。然而，这种强大的表达能力也带来了额外的开销：更多的 LLM 调用、更深的路由逻辑，以及可能出现的循环或不可达路径。为了有效地利用图，请始终将设计与特定用例的需求紧密结合，并避免过度复杂化。

Graphs offer the ultimate flexibility for modeling complex, nonlinear workflows—enabling you to branch, merge, and consolidate multiple tool executions into a unified process. However, this expressiveness comes with added overhead: more LLM calls, deeper routing logic, and the potential for cycles or unreachable paths. To harness graphs effectively, always anchor your design in your specific use case’s requirements, and resist the temptation to overcomplicate.

如果你的任务是严格的线性过程（例如，提示 → 模型 → 解析器），那么首先应该使用链式结构。链式结构易于理解和调试。只有当你需要同时进行分支并最终整合多个信息流时（例如，并行分析步骤生成单个摘要），才应该采用图式结构。

Start with a chain if your task is strictly linear (e.g., prompt → model → parser). Chains are easy to reason about and debug. Adopt a graph only when you must both branch and later consolidate multiple streams of information (e.g., parallel analysis steps that feed a single summary).

在实践中，首先在纸上绘制拓扑图：用工具或逻辑步骤标记每个节点，绘制箭头表示允许的转换，并突出显示分支汇合点。然后逐步实现——限制深度和分支因子，为每个路由器编写单元测试，并利用 LangGraph 的内置追踪功能来验证每条路径是否都通向终端节点。

In practice, sketch your topology on paper first: label each node with the tool or logical step, draw arrows for the allowed transitions, and highlight where branches reunite. Then implement incrementally—cap your depth and branching factor, write unit tests for each router, and leverage LangGraph’s built-in tracing to validate that every path leads to a terminal node.

最重要的是，尽可能保持简洁。每个额外的节点或边都会增加潜在的执行路径和错误模式。如果简单的链或树就能满足你的需求，那就把图模式留给真正复杂的场景。从简单的开始，并根据需求迭代，你就能构建出强大、易于维护且可扩展的编排系统。信心。

Above all, keep it as simple as possible. Every additional node or edge multiplies the potential execution paths and error modes. If a simpler chain or tree meets your needs, save the graph patterns for genuinely complex scenarios. By starting simple and iterating only as your requirements demand, you’ll build robust, maintainable orchestration that scales with confidence.